em1897 at aol.com
em1897 at aol.com
Sun Mar 27 08:46:17 PST 2005
You know, you spout all of this wonderful theory without considering
the quality of the implementation. Everything is implementation.
And a key point that you consistently overlook is that
FreeBSD 5.x is a particularly poor implementation of SMP.
Linux and Dragonfly get 80% improvement in performance
with a 2nd processor, and FreeBSD doesn't. Theory is
meaningless if the implementation sucks, which is more
than just part of the point. The concept that the kernel
is poorly implemented by userland is well done is just not
an assumption that you can make.
From: Anthony Atkielski <atkielski.anthony at wanadoo.fr>
To: freebsd-questions at freebsd.org
Sent: Sun, 27 Mar 2005 12:33:36 +0200
Subject: Re: hyper threading.
em1897 at aol.com writes:
> You can argue the technical theory all you want, but the
> measurements say otherwise.
You have to ensure that you're doing the right measurements.
>FreeBSD 4.9 ->> Load: 38% (I put this in for fun :-)
> Freebsd 5.4-Pre UP (no HT) -> Load: high 55-60% range
> FreeBSD 5.4-Pre SMP/HT -> Load: 70-80% (much more jumping around)
You'll find that the total CPU time required from start to finish for a
single thread is ALWAYS higher for SMP than for a UP environment, even
if you have separate physical processors.
Several things happen when you move from a uniprocessor environment to
an environment with two or more processors:
- The total CPU time for each thread increases.
- The total system load on a per process basis increases.
- The total throughput of the system improves if there is more than one
independent process running in the system.
- Each of the processors runs more slowly than it would if it were the
only processor running in a UP environment.
If you run a single-thread benchmark on a MP system, you'll find that it
runs more slowly than it does on a UP system. If you run multiple
single-thread independent benchmarks on a MP system, you'll find that
total CPU time for each benchmark increases over that required in a UP
system--but the elapsed time required to complete all benchmarks
To properly gauge the performance of a multiprocessor system, you must
run a realistic mix of tasks on the system and measure overall
throughput. If you do this, you'll find that you always come out ahead
with multiple processors, even HT processors.
Hyperthreading is just a special case of multiprocessing that imposes
some additional restrictions. HT is much more sensitive to similarities
in instruction mix across processes, because the actual processor
hardware is being shared. With a sufficiently heterogenous instruction
mix across multiple execution threads, this isn't a problem; but if you
are running a single-threaded benchmark, or a series of identical
single-threaded benchmarks, it can seriously distort your measurements.
Although adding physical processors diminishes the performance of each
processor, it still adds overall processing power, up to a certain
point. The increment is never equal to the actual number of processors
added, though; that is, if you go from one to two processors, you never
get a doubling of effective processor power--it's more like 70-80%. The
percentage increment gets worse with each additional processor, until
you reach a point at which performance actually starts to decline (the
point at which this happens is extremely hardware dependent, but it's
always well beyond two processors).
Hyperthreaded processors should not diminish in performance just because
HT is turned on, because the hardware contention that diminishes
performance in conventional MP systems is largely absent in a HT
microprocessor. However, since you are really still only sharing a
single processor with HT, the overall increment is much lower than it
would be with two physical processors, and it is very sensitive to the
> this shows that you really are a bit foggy. Did you miss the part
> where with 2 processors you actually do have 2 processors?
I actually read what Intel had to say on how the architecture works, and
I spent years measuring systems the hard way (with hardware monitors and
probes), so I know somewhat whereof I speak. Multiprocessing was always
a significant hot-button issue with customers, as they always wanted to
know how much they really gained with multiple processors (as opposed to
what they had been promised).
> I can make an argument that networking with 1 processor on 5.4 is
> better than with 2. For example, with a test similar to the above,
> 2 phyiscal processors FreeBSD 5.4 will start dropping packets way
> it hits 500Kpps unless you increase the interrrupts/second, which of
> course increases the system load. And even with the dropped packets
> (which should reduce the load because it doesnt have to receive
> and transmit the packet), the load is still higher than for 4.x with
> a single processor.
Load is not a problem, as long as it's below 100%. Since individual
processors slow down in MP configurations, anything that depends on raw
processor speed will suffer in an MP configuration. However, overall
system throughput is greatly enhanced by running with several
processors. At the same time, the total processor time required to
complete all tasks is greater in an MP environment than it would be in a
UP environment--it's the fact that things can run in parallel that
improves the throughput.
Moral: if you want to avoid dropping packets in the situation you
describe, increase the interrupt rate. The additional processing power
of the system will make this practical.
> You and many others regulary say things like "SMP is obviously
> or "Opterons are noticably faster", but those statements are only true
> for certain applications.
True, but those "certain applications" are the kind normally executed in
real-world desktop and server systems. If this were not the case,
multiprocessing systems would have been abandoned long ago.
It's almost always better to have a single processor at 2 GFLOPS than it
is to have two processors at 1 GFLOPS, but if you can't get 2 GFLOPS
processors, having two 1 GFLOPS processors is the next best thing.
freebsd-questions at freebsd.org mailing list
To unsubscribe, send any mail to
"freebsd-questions-unsubscribe at freebsd.org"
More information about the freebsd-questions