I just read an article on Heise Online (look at the table, the rest is German) which claimed, that Hyper-Threading slows down single-threaded programs although they don't use the second thread of a core. I.e. if you disable HT in the BIOS, the single-threaded app runs slightly faster.

Is this true or is this a measurement-error? Does anyone has sources about benchmarks which assert the same?

4 Answers 4


It is likely not a measurement error. In fact, this is an eternal debate on the performance of games, since they are usually designed to have the maximum amount of single-core performance. According to this article from Intel article from Intel the Hyperthreading is:

Hyper-Threading Technology from Intel allows one physical processor package to be perceived as two separate logical processors within the operating system. Processor resources enabled for Hyper-Threading Technology duplicate, tag, or share the majority of resources. Sharing resources allows a more efficient use of the processor for a significant performance increase, at less than 5% die size and power consumption increase compared to a single processor package. However, Hyper-Threading Technology cannot have performance expectations equivalent to that of multiprocessing where all the processor resources are replicated.

In the table that you have shown, Cinebench tests one single core of the processor. In short, HT (HyperThreading) enables two virtual cores for one physical core (the one that will be evaluated in the test). If the test is based on launching a single process that does not need to be divided, sharing resources between two cores degrades the test result, since the balance that occurs when it's active doesn't happen when it's disabled (Windows and Cinebench only see a single processor).

If we add another test from Tom's Hardware to compare it with the table you have shown (Cinebench R11.5):

And multi-threaded:

The results on single-thread performance are not so different from the ones that you have shown in your page. It is important to note that the two logical processors that have separate execution states share resources such as the system bus or cache so they can not always parallelize the tasks, and it can happens sometimes thread stalling mentioned in this article that means that in the single-thread stress test, the resource sharing could tend to enqueuing some threads delivering a slightly worse performance result.

You can also see here how different scenarios in different games in the article of overclock.net were the results claims that in some cases the performance is hurt. I do not believe that this has to be taken as "disable HT improves the single-thread performance" but as "the game is optimized for a maximum of 4-cores" or "is not taking advantage of the HT". The first assumption can be validated reading some articles like this, which shows how the single-core performance of an i3 improves the performance if the HT is enabled comparing with i7 that it doesn't.

To sum up, we have seen that there are small cases that disabling HyperThreading has minimal improvements over the single thread performance, but the overall cost-benefit ratio it isn't enough to claim disabling HyperThreading. As far as the OS and the software it is designed to HT architecture, it is not worth to disable it.

  • Updated answer. Jan 13, 2017 at 13:55

Yes and it should be obvious. When you enable HT you advertise twice as many cores as there are.

This is designed to let more parallelization happen on the basis that most programs are not sufficiently multi-threaded. However, if you fully multi-thread a program, then you overcommit resources and there is a performance drop just because of the extra overhead per thread. However small this may be, with an application than managed to use 100% CPU over any number of cores and processor, enabling HT resulted in a roughly 2-3% drop in performance.

Now in the case of an isolated single-threaded program, it sounds like it should not matter since the program itself cannot overuse resources but remember than the OS also thinks there are extra cores and that can overcommit resources. Even if there are still unused cores, one can measure overhead caused by the scheduler which does not optimally place the thread and lock it to a single real core.

These observations are based on over a decade of real-time software development and benchmarks. There is clearly an observable difference, although a very small one, when one tries to maximize the performance of a system.

  • 2
    You managed to get almost every important point about HT completely wrong. First, adding more cores, virtual or otherwise, doesn't magically make programs which are not very multithreaded to become more so, anymore than adding more physical cores does. Secondly, multithreading overhead is entirely dependent on the program and implementation, and regardless, is totally irrelevant to HT. You seem to have a very deep misunderstanding of how HT works.
    – metacollin
    Feb 19, 2020 at 21:14
  • HT doesn't result in 'over committing' resources. HT is giving each execution core two architectural state units (pipeline, decoder, interrupts, registers, every thing an entire extra physical core would have, except for the execution core itself). Since any HT'd CPUs are superscalar, this means they can reorder instructions and any time there is data specific to each logical core that needs the same operation performed, that instruction can be executed on both thread's data simultaneously.
    – metacollin
    Feb 19, 2020 at 21:24
  • This obviously will have anywhere from a negligible to substantial improvement in performance depending on how often two threads both need to perform the same operation on different data. But its important to note that any modern OS and CPU isn't 'over provisioning' anything. Each thread gets its own core, and it is only when the number of threads exceeds the physical cores that logical cores come into play. At this point, there are no resources left anyway, but at least you can combine certain operations to use each execution core to do that much more per instruction.
    – metacollin
    Feb 19, 2020 at 21:29
  • But, arguably the main benefit from HT is that it results in a profound reduction in pipeline stalls (when the execution core of a CPU is sitting idle because it is waiting on data that wasn't in the L1 cache to get loaded from L2/L3/or worst case, even system RAM). Without HT, all that time is simply wasted. With HT, the moment one pipeline stalls, guess what - there is that entire second pipeline as well. So if either thread ends up waiting on data, then if the other thread isn't, the core can execute those instructions. Every instruction completed is one more than no HT could have done.
    – metacollin
    Feb 19, 2020 at 21:33
  • 1
    Also, your observations are, ultimately, little more than anecdotes and it doesn't matter how many years of them you have. A mountain of real world benchmarks, measurements, and data comparing HT on vs off, done using an incredible variety of tasks, is one google search away. And it overwhelmingly contradicts your anecdotes. And no offense, but using anecdotes when others have actual data... you're bringing a knife to a gunfight. Your observations don't even mention what OS, the workload, the number of cores. Because what you describe depends on all that, it isn't generalized to HT.
    – metacollin
    Feb 19, 2020 at 21:42

No benchmarks, but it's probably true, based on the following:

From the Wikipedia article on "Hyper-threading":

... however, when running two programs that require full attention of the processor, it can actually seem like one or both of the programs slows down slightly when Hyper-Threading Technology is turned on. This is due to the replay system of the Pentium 4 tying up valuable execution resources, equalizing the processor resources between the two programs, which adds a varying amount of execution time.

This is something that doesn't apply when SMT is disabled - the OS then distributes threads among cores and not hardwarethreads.

Modern Intel (and AMD) CPUs do "speculative execution" where they actually fetch and pre-execute instructions ahead of the current instruction pointer, to have results ready when actual execution catches up.

Things like non-expected branches and interrupts cause the CPU to throw away its speculation and have to start over, and it sounds like SMT introduces more situations where that can occur. For "straight tasks" that don't branch or deal with many conditions (i.e. GPU-ish tasks) it likely provides a benefit.


When you have HT enabled, the CPU splits itself in to two logical CPUs, and both CPUs are considerably slower than than the single core that they came from, but the combined power is over 100%. In the Pentium 4 days, you could split one CPU core in to two logical cores that are about 55% as fast. With the Hyper Threading added back to the Core architecture, it has gotten better than 55%.

The problem is that the operating system tends to treat the logical cores as physical cores, so a high priority task can run along side a low priority task in the same CPU core. Now both threads or tasks are getting equal CPU attention even though they shouldn't be due to the priority difference. When you run a benchmark, the OS may schedule low priority tasks in the logical cores and slow the benchmark program down. Of course when one logical cores becomes idle, HT is effectively disabled and the remaining core returns to 100% speed.

Imagine a busy server with a CPU intensive screen saver. The screen saver comes on, and even though it is set at low priority, it ends up splitting a CPU core in to two parts that are 65% as fast. Now the server only has 65% of a CPU core available.

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