Just like the thread title asks, what is the point? I've owned numerous computers and done numerous tests, and the computer is ALWAYS faster with hyperthreading disabled than with it enabled...every single time. So, what is the point?

I have a multi-processor modeling program at work. I can run it on anywhere between about 1-6 procs (above 6 it starts slowing back down). In every test I've done, from 1-6 procs, it runs about 10-20% faster if hyperthreading is disabled than if it's enabled, even if it's trying to run on more procs than the system has. Running 4 threads at 50% on two real cores is faster than running 4 threads at 100% on four virtual cores (two real cores with hyperthreading).

I have another acquisition system running on an Intel Atom 2 GHz proc. I set up one system (forgot what all I had done during setup) and the acquisition process was consuming about 80% CPU consistently and everything was great. About a year later I set up a second one and the acquisition process was consuming about 130% CPU and was dropping samples constantly. After a couple of hours of experimentation (different optimization levels in the compiler, etc) with no success, I finally dropped into the BIOS and disabled hyperthreading. Instantly, CPU usage dropped to 80% and it stopped missing samples and everything was great like the first system (apparently I had disabled hyperthreading on the first system before doing any tests).

As far as I can tell, all hyperthreading does is slow things down with no redeeming qualities, but if that were the case I doubt it would be so common/popular. Right now, the first thing I do when setting up ANY system is disable hyperthreading. So under what conditions does it actually help?

If Hyperthreading is beneficial depends on the tasks you run. Hyperthreading works best if you run tasks simultaneously that use different units of the CPU, for example a text editor and a media-encoding program. Nowadays Hyperthreading (aka SMT) is much more advanced than in the Pentium 4 CPUs, when it was introduced. For example, AMD's FX CPUs use an advanced form of SMT, so advanced that AMD's marketing department calls their 4-module CPUs 8-core instead. But even here it is highly dependent on the workload if SMT is beneficial. Also, the OS must be aware of the differences between logical and physical CPUs to get the benefits, otherwise it is possible that the kernel schedules the tasks to the wrong CPU, which is slowing down the system.

You might want to have a look at this article with benchmarks: http://www.tomshardware.com/reviews/...980x,2584.html

Those test results are odd to say the least. What they show is a remarkable improvement in execution speed with HT enabled for most applications, and a very slight reduction in execution speed with HT enabled for some applications.

Unfortunately my experience has been the exact opposite in a variety of both single-threaded and multi-threaded applications, on systems ranging from Atom Z550 to Xeon X5690.

Perhaps the takeaway from this is that anybody interested in improving system performance should ignore online tests and do their own benchmarks to see the effect hyperthreading has on their actual systems and processes. Until I encounter a real-world application that I use on my system who's performance is improved with hyperthreading (versus slowing down), I'll continue to leave it off.

Thanks for the link, it was educational.

This is something that is not only true for Hyperthreading, but for everything. Whenever you have to evaluate a system or software solution you have to make your own benchmarks with your own workload. Benchmarks made by other people can always be seen as indicator only.

I work on a simulator product in which multiple threads (when used) are all doing essentially the same thing. They might all be limited by floating point performance, so enabling hyperthreading slightly reduces throughput, or they might all be limited by cache misses, so enabling hyperthreading dramatically reduces throughput. I don't know of any case of any of my employer's simulator products running better with hyperthreading enabled.

BUT I actually spend a lot more computer time recompiling the product than running it. I often work on key parts of the code that are templated in .hpp files that are depended upon by a large fraction of a very large project. So testing a small change requires recompiling a massive amount of code.

All my tests with our build system show that running a lot of compilers in parallel with hyperthreading enabled has better throughput than running either the same or fewer compilers without hyperthreading. Most of that testing has been under Windows, but such testing as I have done under Linux reveals similar results.

I expect there are a lot of other workloads in which hyperthreading helps. Running many compilers in parallel is not the reason hyperthreading exists.

"modeling" can mean enough different things that I shouldn't guess the performance characteristics of that product from that word. But based on my experience with a variety of different simulators (semiconductor, electromagnetic, mechanical, thermal, fluid, chemical, etc.) I think you might also be in some area where hyperthreading is harmful. That doesn't mean such results apply to everyone.