It often depends on how related the datasets of the two hyperthreads are.  If both HTs are working on the same data, then it can often be a win for the reason you state - increased instruction level parallelism, and of course the opportunity to do work while one thread is stalled on a non-overlappable miss.<p>If the two threads are not so related, they can easily trash each others cache and have a substantially negative impact upon performance.  Ulrich Drepper has a pretty good discussion on page 29 of this doc ( <a href="http://people.redhat.com/drepper/cpumemory.pdf" rel="nofollow">http://people.redhat.com/drepper/cpumemory.pdf</a> ).<p>It boils down to this: Code that has a low cache hit rate can often benefit from HT, as it can usually be parallelised into two threads that have a not-much-worse cache hit rate, and there will be plenty of gaps to fill.  More optimised code stands to lose quite significantly, as parallelising code with a high cache hit rate to (a) not trash each others cache, and (b) still have a very high hit rate, is very hard.