Cogman
Lifer
- Sep 19, 2000
- 10,286
- 147
- 106
I don't know if it is the best way. More, it is a way.Yes, exchange is one of those "niche applications" that could be impacted.
http://blogs.amd.com/work/2010/01/21/it’s-all-about-the-cores/
I will not argue the fact that there are places that SMT can bring a throughput increase. I will, however, argue that it is the best way to deliver more throughput. Anytime I see an enterprise software application recommend turning off a feature in order to provide more stability or accuracy, it's a big red flag for me.
HT benefits primarily from different threads using different areas of the CPU (SIMD instructions, FPU instructions, ALU instructions, and movement instructions to name a few.) The reason some programs won't benefit from it is, most programs don't begin to use the instruction set on a cpu.
It doesn't make sense to break up an application that primarily uses one part of the CPU in a hyper threading environment. It will still only use that one part of the cpu, causing collisions galore (best case, losing no performance, worst case, seeing a decrease in speed.) Most business applications fall into that category. The FPU is simply rarely touched in a business environment (unless they are doing stock predictions)
Now, if you have an app the uses, fairly heavily, multiple modules from the CPU, then threading it in a hyperthreading situation makes sense. Each thread will be doing different things, giving a good chance that one thread will start using the FPU while the other is using the ALU.
I do agree with you though, a properly coded multi-threaded application shouldn't suffer stability issues with or without hyperthreading. It may, however, see no performance benefits, and even a performance decrease.
