Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
1  
What model of Intel CPUs are you using,e.g. Core i5 or i7? –  JB King Mar 31 '11 at 14:46
    
@JBK Good question, I don't know, I don't have one of those machines myself. –  Pops Mar 31 '11 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. –  Steve314 Jul 22 '11 at 14:48
    
In the Lucasarts game Grim Fandango the sound engine ran into a race condition when running with hyperthreading. –  user1249 Jul 23 '11 at 11:42

7 Answers 7

up vote 11 down vote accepted

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.)

share|improve this answer

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.

share|improve this answer
    
It's also known to make some games run slower than when hyperthreading is deactivated. –  Klaim Mar 31 '11 at 16:17
3  
It would be interesting if they were concerned about the performance of games played at work. –  dietbuddha Mar 31 '11 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... –  Steve314 Jul 22 '11 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 '11 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.

share|improve this answer
1  
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. –  Patrick Hughes Jul 23 '11 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.

share|improve this answer

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.

share|improve this answer
    
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). –  Steve314 Jul 22 '11 at 14:58

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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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