MS SQL Server 2008 Power Analysis

We'll let power consumption be the final judge:

Concurrency CMT No CMT Power Increase
CMT vs. No CMT
HTT No HTT Power Increase
HTT vs. No HTT
25 144 141 2% 159 156 2%
40 156 160 -2% 169 163 4%
80 185 194 -5% 182 174 4%
100 211 209 1% 192 177 8%
125 223 224 0% 201 186 8%
200 250 254 -2% 235 213 10%
300 290 283 3% 277 251 10%
350 305 288 6% 299 275 9%
400 316 288 10% 303 275 10%
500 316 291 9% 314 275 14%
600 324 299 9% 312 285 9%
800 324 308 5% 320 289 11%

CMT increases the amount of power consumed by 6-10%, but only at high loads. The extra clusters probably allow the modules (as AMD likes to call the cores) to sleep more frequently at lighter loads, and we measure no increase or even a small decrease in power consumption. The message is clear: there is no reason to disable CMT when running MS SQL Server.

Hyper-Threading seems to increase the power dissipation always. At higher concurrencies, the higher performance must be paid with a 10-14% power increase, so you might consider disabling Hyper-Threading if your want to cap maximum power output for some reason (e.g. getting to close to the maximum amount of amps allowed in your rack).

MS SQL Server OLAP Conclusion

We invested 10 times more time in our MS SQL Server testing, but frankly we are glad we did. The Opteron 6174 seems to be a true champion from a simple "throughput/power at 100%" analysis, but the reality is that servers hardly ever run at such loads. Under light loads, the Opteron 6174 is either slower and consumes more power (Balanced power setting) or it consumes quite a bit more (High Performance power setting) while being roughly on par with the competition in terms of performance. At medium load, the Opterons are beaten solidly by the Xeon; the Xeon consumes quite a bit less power in "Balanced" and performs a lot better (response times).

At the end of the day, the Xeon X5650 is the better chip (especially in "Balanced" mode) but it's also the more expensive one. The Opteron 6276 price/performance/watt ratio remains quite attractive, but if pricing is taken into account everything will depend on which MS SQL Server License you will get. We will leave that analysis to other people as an economic analysis of complex, customer unfriendly licensing is definitely out of the scope of this article.

Threading Tricks or Not? MySQL OLAP Testing
Comments Locked


View All Comments

  • Scali - Friday, February 10, 2012 - link

    No, because if you read the ENTIRE benchmark configuration page, you'd see that all the AMD systems had 2 CPUs as well.
  • Scali - Saturday, February 11, 2012 - link

    Oh, and while we're at it... the Intel system had only 48 GB of 1333 memory, where the AMDs had 64 GB of 1600 memory.
    (Yes, Bulldozer is THAT bad)
  • PixyMisa - Saturday, February 11, 2012 - link

    Or rather, MySQL scales that poorly.

    What we can tell from this article is that if you want to run a single instance of MySQL as fast as possible and don't want to get involved with subtle performance tuning options, the Opteron 6276 is not the way to go.

    For other workloads, the result can be very different.
  • JohanAnandtech - Saturday, February 11, 2012 - link

    Feel free to send me a suggestion on how to setup another workload. We know how to tune MySQL. So far none of these settings helped. The issue discussed (spinlocks) can not be easily solved.
  • Scali - Saturday, February 11, 2012 - link

    I'm not sure if you bothered to read the entire article, because MySQL was not the only database that was tested.
    There were also various tests with MS SQL, and again, Interlagos failed to impress compared to both Magny Cours-based Opterons and the Xeon system.
  • JohanAnandtech - Saturday, February 11, 2012 - link

    The clockspeed of the RAM has a small impact here. 64 vs 48 GB does not matter.
  • Scali - Saturday, February 11, 2012 - link

    Not saying it does... Just pointing out that the AMD system had more impressive specs on paper, yet failed to deliver the performance.
  • JohanAnandtech - Saturday, February 11, 2012 - link

    Again, it is not CMT that makes AMD's transistor count explode but the combination of 2x L3 caches and 4x 2M L2-caches. You can argue that AMD made poor choices concerning caches, but again it is not CMT that made the transistor count grow.

    I am not arguing that AMD's performance/billion transistors is great.
  • Scali - Saturday, February 11, 2012 - link

    I think you are looking at it from the wrong direction.
    You are trying to compare SMT and CMT, but contrary to what AMD wants to make everyone believe, they are not very similar technologies.
    You see, SMT enables two threads to run on one physical core, without adding any kind of execution units, cache or anything. It is little more than some extra logic so that the OoOE buffers can handle two thread contexts at the same time, rather than one.

    So the thing with SMT is that it REDUCES the transistorcount required for running two threads. By nearly 100%.
    CMT on the other hand does not reduce the transistorcount nearly as much. So if you are merely looking at an 'exposion of transistor count', you are missing the point of what SMT really does.

    Other than that, your argument is still flawed. Even an 8-thread Bulldozer has a higher transistor count than the 12-thread Xeon here. It's not just cache. CMT just doesn't pack as many threads per transistor as SMT does... and to make matters worse, CMT also has a negative impact on single-threaded performance (which again, if you are looking at it from the wrong direction, may look like better scaling in threadcount... but effectively, both with low and high threadcounts, the Xeon is the better option... and this is just a midrange Xeon compared to a high-end Interlagos. The Xeon can scale to higher clockspeeds, improving both single-threaded and multithreaded performance for the same transistorcount).

    So what your article says is basically this:
    CMT, which is nearly the same as having full cores, especially in integer-only tasks such as databases, since you have two actual integer cores, has nearly the same scaling in threadcount as conventional multicore CPUs.
    Which has a very high 'duh'-factor, since it pretty much *is* conventional multicore.
    It does not reduce transistorcount, nor does it improve performance, so what's the point?
  • JohanAnandtech - Friday, February 10, 2012 - link

    Semantics :-). I can call it a core with CMT, or a module with 2 cores. Both are valid.

Log in

Don't have an account? Sign up now