My company just bought new computers to replace old 2GB Windows XP machines. Someone on my team noticed that they came with hyperthreading disabled, and told everyone to reboot and turn it on. Is there a benefit to programming on a machine with hyperthreading disabled?
Yes I've worked on an app which performed better when running on a machine with HT disabled.
What happened was, the original code would create twice as many as threads when run on a hyperthreaded machine (which you'd assume is sort of the whole point of HT). However, the throughput of those threads was very sensitive to the amount of cache available to the thread. With twice as many threads fighting for a fixed amount of cache, cache available per thread was too low and thrashing occurred: there'd be loads more cache misses, loads more main-memory accesses, and performance took a substantial hit compared with running with less threads and more cache per thread (which is what you got if you ran the app on a machine with HT disabled).
The ultimate fix was to have the app check the HW platform better and take cache sizes and the amount of cache considered needed per thread into account when deciding how many threads to create. In any case the issue quickly disappeared with the subsequent generation of CPUs, which doubled cache size (and we actually started seeing a modest benefit from HT then). However, the whole episode left a long and lasting legacy of recommending HT always be disabled on any platform our SW ran on, and knee-jerk "that machine hasn't got HT enabled has it?" responses to any performance problem. (I think the fundamental problem is most non-geeks simply don't understand what HT actually is.)
I don't know the technical details, but apparently if an app (or the OS) is not optimized for hyper-threading, hyper-threading can actually decrease performance.
Even Intel recommends turning it off in this case:
The following desktop operating systems are not recommended for use with Hyper-Threading Technology. If you are using one of the following desktop operating systems, it is advised that you should disable Hyper-Threading Technology in the system BIOS Setup program: [...]
So maybe the manufacturer (or the supplier) wanted to be careful.
More than likely, the OEM was just being conservative. OEM's often ship with advanced featuers disabled (like HT, No-Execute bit, vt, etc..) turned off. The reason is that some rare circumstance might make those settings fail, and people that actually want the features can just as easily turn them on.
Also, some rare bugs in OS's have lead to potential security issues when some features are enabled. virtualization technology, for instance, once had such a problem. So, it's just the vendor being conservative.
Hyperthreading is generally useful for interactive desktops, like programming machines. Although, some people might want to turn it off if your apps are going to run on servers without HT. Just to reduce potential hardware differences.
Hyperthreading doesn't add new cores to the CPU. You still have one arithmetic/logic unit, one floating point unit (...) per core. So if you have multiple threads/processes that do very different things, HTT can improve performance. But if you have multiple threads doing more or less the same things (not uncommon in number crunching applications), performance can actually suffer badly from HTT.
Maybe cache-coherence issues in massively multithreaded code? If you have discrete CPU caches, it's theoretically possible for two threads to have the same data cached and modify it at the same time with different values. If you have a unified cache at some point between the CPUs and main memory (either L2 or L3), then there's probably some mechanism in place that will prevent this, but on lower-end CPUs with smaller caches, maybe not.
Alternately, it may be possible that enabling hyperthreading on chips that don't support it will throw a code during POST, so the BIOS supplier just leaves it off because they don't know what kind of CPU the system will have.
One reason not to turn off hyperthreading on a developer machine is that it may hide some subtle multi-threading bugs. But this only really applies on a single-core single-processor machine. Multi-core will expose, if anything, more multi-threading bugs during testing.
OTOH, I doubt you'll see a single-core processor with hyperthreading disabled by default. My vote is on Sleskes answer.
A lot of old software was written on single core machines, and may have had bugs in it when running on a multicore machine. Probably the instruction was really meant to say "This doesn't work in multicore machines", it's just that for a long time hyperthreading was the only likely multi-core machine you'd see in common use.