hyper threading.

Anthony Atkielski atkielski.anthony at wanadoo.fr
Sun Mar 27 01:34:36 PST 2005


Paul A. Hoadley writes:

> Here are some measurements.  A few weeks ago I ran Unixbench 4.1.0
> (/usr/ports/benchmarks/unixbench) on a P4 2.8GHz with and without
> hyperthreading enabled.  I note a slight difference in the 10 minute
> load average in favour of the uniprocessor run (0.00 vs 0.10 in the
> hyperthreading run), though I doubt this alone could account for a 15%
> difference in total score.

It's not clear to what extent these measurements represent simultaneous
processing.

The presumed advantage of hyperthreading resides in the ability to make
better use of the processor hardware when you have more than one
execution thread running AND the threads are doing entirely different
things.  Intel has demonstrated this by running completely different
tasks at the same time on HT and non-HT systems; the HT systems
consistently perform better.  Both desktop and server systems can
benefit from this.

However, if you run measurements that consist of a single execution
thread, or several execution threads performing the same type of work,
HT will probably be slower than a UP environment.  In this case, HT
contributes nothing because the various threads are competing for the
same processor hardware at the same time, so the global instruction rate
does not improve with HT--and since SMP has higher OS overhead than a
uniprocessor environment, the net result is a loss of performance.

In order to profit from HT, then, you must have a mix of different tasks
running on the system at the same time.  This should be the normal case
for most desktop and server systems, but it is never seen in benchmarks
unless they are specifically designed to simulate this.  Thus, while HT
may help in real-world applications of servers and desktops, the only
way to see this in measurements is to make sure they duplicate the type
of instruction mix seen on these systems in real life.

The actual architecture of hyperthreading is pretty straightforward, and
it's pretty clear that it cannot result in degraded performance: either
it improves performance, or it makes no difference.  So the only
question is whether or not HT improves performance enough in a
real-world environment to offset the greater OS overhead of managing
multiple processors.  I think that with a heterogenous instruction mix
of the type likely to be seen in real-world systems, it does (admittedly
not by much).  In some systems that are doing a lot of homogenous
number-crunching, performance might go down, but it's difficult to
imagine such a scenario for a server.  Some desktops might be in that
situation, if they are dedicated to single tasks (games, Mathematica,
CAD, etc.).

-- 
Anthony




More information about the freebsd-questions mailing list