hyper threading.

[Anthony Atkielski]

em1897 at aol.com writes:

> Yes, the theory is very nice; you've done a nice
> job reading Intel's marketing garb.

I haven't read their marketing materials.  I'm simply going by the
technical descriptions I've read of the architecture.

> However if you don't have a specific hyperthreading-aware scheduler
> and particularly well-written, threaded applications, you'll lose more
> than you'll gain.

If that were true, then it would be equally true of systems with actual
multiple physical processors.  In practice, multiple processors provide
an obvious performance gain, and hyperthreading does, too, although it's
much more modest than the gain obtained from physically independent
processors.

> Since FreeBSDs network stack isn't particularly well threaded, nor is
> the scheduler optimized for hyperthreading, you get a big mess at the
> kernel level.

Nothing needs to be specially optimized for hyperthreading.  All you
need is at least two threads available for dispatch, with reasonably
heterogenous instruction mixes that can use different parts of the
processor hardware at the same time.  Real-world instruction mixes are
often in this category in general-purpose operating systems.

> So if you have a nice application that does a lot of threaded math
> operations, you might think you've achieved something,

Heavily math-oriented applications (or any group of applications that
contains similar instruction mixes) are among the least likely to
benefit from hyperthreading, because they will tend to use the same
processor logic at the same time, effectively rendering hyperthreading
moot.

> But what you've missed is that the overhead to manage
> the "better utilization" of the dual-pipelines created
> by HT costs more than it gains.

Unless FreeBSD is very poorly written indeed, the gain from
hyperthreading should still exceed the slight increase in overhead
incurred by multiprocessing logic.

> Hence, the loss of performance.

Where can I see this loss of performance documented?

> The poblem is not at the application level, but at the kernel level.
> The SMP overhead is so substantial, and the OS is working thinking it
> has 2 processors, that process switching and interrupt handling slow
> down considerably.

How much is "so substantial"?  Where can I see this documented?

> A machine with a 50% load UP will run 65-70% load with
> HT/SMP running. Like I said, its easily measurable.

Then you can show me the measurements.  Where are they?

A 40% increase in system load just because of multiprocessing is
enormous.  Where did you get this figure?

> Thats at the kernel level (say routing or bridging performance).

But the kernel is only a small fraction of overall processor
utilization.

> Now if the machine isn't a server, it may be just fine.
> Thats why I suggested testing. But for a network server
> HT is bad. Very Bad.

It doesn't matter whether the machine is a server or a desktop.  What
matters is the specific mix and nature of applications.

> Not only that, but FreeBSD 5.x actually has a higher
> capacity network-wise with 1 processor than 2 ...

Here again, I need to see this documented.

> ... and I'm sure you can theorize why 2 processors should be
> faster than one. The theory only matters if you have
> well written code to handle it properly. FreeBSD is
> a long way off from that.

Where can I see the measurements?

-- 
Anthony