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?


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. – gorosjosu Jan 13 '17 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.


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.

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.