Until Red Hat’s improvements make it into the Linux kernel, sysadmins are going to have to decide whether hyperthreading benefits their user setups. That may be a hassle, but it beats taking a performance hit from a feature that is supposed to do just the opposite. Read the article at NewsFactor.
A Linux Mystery: Configuring for Virtual Processors
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
The author was virtually contradicting himself throughout the article. It’s a very petty issue to begin with. You hardly lose any performance with hyperthreading turned “on” while running a singe-threaded application. Red Hat is apparently working on a fix to deal with the virtual and physical cpu handling anyway it said.
To say that the article is rather insignificant would be an understatement.
sysadmins are going to have to decide whether hyperthreading benefits their user setups.
I have decided that users don’t get any benefit from hyperthreading, so we will be switching to AMD CPUs.
the article initially suggests that the peformance _gain_ varies from OS to OS on hyperthreading, due to a varying recognition of the fact that the 2 CPUs are not really physically different (end hence compete for the same cache etc).
however, the most important point of the article, right at the end, that there can actually be a _loss_ in performance, is not explained. how, why? which circustances to avoid?
t
Here is what happens
Linux divides the tasks evenly between processors but with hyperthreading that is not optimal because one processor is running at 30% of the other. So one process runs normally and the other runs at 30% of the speed of the other. One will always finish faster when they should be running at the same speed.
Linux should divide the tasks unevenly between the processors that way you get a more optimal effect.
The reason it happens is that Linux doesn’t understand that the second processor is logical and thinks it is physical and can run a full load.
Richard James could hardly be more wrong. The logical processors do not on average run at different speeds, that would be a stupid design.
The two logical CPUs share all the normal resources of the CPU, except that each has its own registers, and instruction queue. The hardware attempts to schedule instructions from each logical CPU in turn. To do this it needs resources (units within the CPU) and often both logical processors need the same unit at the same time, so one must wait and there’s no speedup.
Sometimes though one logical processor (perhaps running a kernel compile) mostly uses the ALU while another makes extensive use of the FPU. Situations like this result in a large speedup. Also sometimes one logical processor is waiting for (relatively) slow RAM, while the other is able to proceed using cached data. Again a large speedup.
To make these speedups more likely you need an HT-aware OS (like Red Hat 9 or WinXP) a special instruction mix optimisation setting for your compiler, and/or a carefully designed multi-threaded application which separates operations of unrelated types as much as possible.
However there is a downside to alternating code from two logical processors. They share a single code & data cache. If the code running on both logical processors is cache hungry there will be more cache hits. This can begin to unravel the advantages described earlier, and with a non HT-aware OS scheduler it’s all too easy for this to cause a noticeable overall reduction in performance.
‘cache hits’ should say ‘cache misses’ of course. Thinko.
I guess only real experience can tell. Only real testings in real situations. As each situation is different, each administrator will have to configure it to have the best run-time performance for each use.
I dont think the article is very clear on the problem. It first states that HT will give speedups and then mentions it will sometimes be slower. It should have be noted repeatedly that turning on HT will only be problem on multiple CPU systems. On single systems HT will always(*) be benificial.
(*) except for a few unlikely and weird cases
Really? Most software today is threaded? Care to back that up Mr. Ryan?
Lots and lots of software, especially in the Unix world, is single-threaded because *nix OS’s haven’t had thread support for very long. Instead, they depend on low process overhead at the OS level, and just fork() a lot of child processes.
On the other hand, most people don’t care about every program on their system being fast; they just care about a handful, or maybe one, being as fast as possible. (And sometimes the CPU isn’t the bottleneck.) So it kinda doesn’t matter if even a handful of programs are multithreaded and are coded for hyperthreading – what matters is if the application that you care about is, or not.
Richard James could hardly be more wrong.
I’m only human