Aiden's Rules of Thumb
ShnikeJSB said:
Does this mean that when the Intel Macs finally DO come out, they will be HyperThreaded? And hopefully by then Intel will have the quad-cores out, and with hyperthreading, that means 8 threads!!!
Hyper-Threading is a perfect example of YMMV (Your Mileage May Vary) - it's not always good, not always bad. It's never as good as additional cores, and it's not something to get overly excited about, Robin.
My basic rules of thumb about whether to turn HyperThreading (HT) on or off are:
- Does the O/S understand the difference between logical and physical CPUs, and do a good job of scheduling threads? (Win2K/Linux2.4 - bad, XP/Linux2.6 - OK, Win2k3 - good)
- Does the application usually have more active (computable) threads than logical CPUs?
- Am I interested in response time or throughput?
HT-unaware systems like Windows2000 don't understand that a logical CPU shares resources (cache and execution units like adders, multipliers, load/store...) with other logical CPUs, and doesn't understand which pairs of logical CPUs are on the same physical CPU (core).
This means that they'll often run two jobs on the same core, and leave other cores idle. Usually not a good choice, although some specific apps can benefit from sharing the cache (best to let those apps control their own processor affinity).
HT-aware schedulers will try to spread jobs between cores first, then double up as the number of active threads increase. In a dynamic environment, however, this changes millisecond by millisecond - so sometime you have two threads running on one core, and the other cores idle. The threads can be rescheduled on the idle cores, but this has a bit of overhead involved.
______
At the application level, if you have lots of active threads, then you're more likely to always have all logical CPUs busy, and to benefit from HT. If you have fewer threads than logical CPUs, then you're exposed to the scheduling problem above.
______
Another important issue is whether you're interesting in response time or throughput.
If you have a task that takes 60 CPU seconds, then with a single CPU you can do 60 per hour. Pretty simple.
If your single CPU is hyperthreaded, then you can run two at once. Due to contention for the execution units, however, each job will take longer - say 90 seconds. (I see 50% to 80% stretch on many apps.) Since you're running two jobs at once, you're pumping one out every 45 seconds on average. This means with HT you can do 80 jobs per hour - 20 more than without HT.
That's the response time vs throughput dilemma - is it better to do 33% more even though each one takes 50% longer?
______
So, applying these rules, I get:
- Single core desktop - turn HT on. You usually only have one thread, and you get a boost when you have more.
- Dual core desktop - turn HT off. You're proably interested in response time, not throughput. When you have more than one thread, let it use the second core and don't risk the extra threads ending up on the same core. (Exception: Windows Media Encoder handles 4 threads very well - when I'm going to do a bunch of video encoding I'll turn HT on and let it keep them all busy.)
- Servers - off if won't have lots of threads computable, on for web servers, file servers and other tasks with lots of threads.
