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?

  • 1
    What model of Intel CPUs are you using,e.g. Core i5 or i7?
    – JB King
    Mar 31, 2011 at 14:46
  • @JBK Good question, I don't know, I don't have one of those machines myself.
    – Pops
    Mar 31, 2011 at 15:06
  • On an old Pentium 4 notebook, to reduce heat and fan noise, and maybe make the battery last a few more minutes. Not an answer because it should be an ancient history thing, and shouldn't apply in your case.
    – user8709
    Jul 22, 2011 at 14:48
  • In the Lucasarts game Grim Fandango the sound engine ran into a race condition when running with hyperthreading.
    – user1249
    Jul 23, 2011 at 11:42

7 Answers 7


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: [...]

(Source: http://www.intel.com/support/processors/sb/CS-017343.htm )

So maybe the manufacturer (or the supplier) wanted to be careful.

  • It's also known to make some games run slower than when hyperthreading is deactivated.
    – Klaim
    Mar 31, 2011 at 16:17
  • 4
    It would be interesting if they were concerned about the performance of games played at work.
    – dietbuddha
    Mar 31, 2011 at 16:50
  • On a multi-core system, two threads might be allocated to two hyperthreads on the same core, leaving all the other cores idle and giving much less performance than putting each thread on a different core. Until operating systems become aware of the difference between a different core and different hyperthreads on the same core...
    – user8709
    Jul 22, 2011 at 14:50
  • 1
    @Steve314: That was certainly the case back with Windows2000 (and disabling HT was definitely a good idea if you were running that) but Windows XP was supposed to be HT aware (see e.g download.microsoft.com/download/5/7/7/… ) and not fall into such a trap. I assume similar logic got built into Linux from some version of the kernel.
    – timday
    Jul 22, 2011 at 18:57

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.

  • 2
    This is almost always the case for machines that come with HT turned off. Maximum compatibility and saving the vendor from a flood of weird support calls. Jul 23, 2011 at 0:58

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.

  • My guess - there's a mechanism in place to resolve this coherence issue, but it may have a significant performance penalty. IIRC, a particular page of memory cannot be freely loaded into just any cache page - there's typically a this-address-maps-to-one-of-these-few-pages mechanism. Maybe it's possible for two threads to fight over a few cache pages, leaving the rest unused? (maybe even with multi-core, though presumably with less risk).
    – user8709
    Jul 22, 2011 at 14:58

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.