Robert said:
In any case, the point of the InfoWorld article was that the Xeon
workstations excelled on mixed workloads...the kind an actual
workstation user _might_ experience...different for different kinds of
users to be sure, but a better measure of workstation performance
than a database benchmark.
Intel hypes hyperthreading every chance it gets because it's something
Intel's got that AMD doesn't. There's been much online discussion
among people who could be expected to be knowledgeable, and the best
conclusion I can draw about SMT is that, as a design strategy, it's a
wash...if you consider performance per watt or performance per
transistor. That leaves open the question of responsiveness. Anybody
who uses a workstation and does CPU-intensive work has had the
experience of having the system become annoyingly slow. Does
hyperthreading help with _that_? The InfoWorld article suggests that
it does, and a database benchmark doesn't seem particularly relevant.
Actually the problem with the Infoworld article is that it's not even really
a true test of multitasking performance. If you read the article, and then
do some checking up on the tools used, it's very shady. First of all, the
benchmarking application is described on the company's website here:
http://analyzer.csaresearch.com/
It's actually called *HTP* Analyzer (i.e. Hyperthreading Analyzer). So it's
a benchmark specifically designed for and geared towards Hyperthreading.
Therefore it's aware of how to detect it, and how to make full use of it. If
you read through the description of this benchmarker a little bit, you'll
find there are two major components of this benchmark suite. First
component, it states that it can test real-world applications through a
test-script functionality; and second, it tests the system's multitasking
efficiency by running simultaneous background workloads. So you think that
since it runs real-world apps in a test-script, therefore it must be one of
those good applications benchmarks and not one of those bad synthetic
benchmarks. However, then you read about what it uses to load down the
background tasks with. According to its webpage, it creates "simulations" of
real-world workloads such as Database, Workflow, and Multimedia. Now these
aren't real database, workflow or multimedia applications, just simulations
of them -- so they are synthetic workloads. He's not running multiple
simultaneous real-world applications; he's running only one real-world app
thread, but several synthetic app threads to load it down. It's a synthetic
benchmark cleverly masquerading as an applications benchmark.
Now, how could this benefit a Hyperthreading processor over a non-HT one?
Well, in an HT CPU, the benchmark can configure it such that it runs the
applications test-script in the primary HT logical processor, while all of
the synthetic load-generating simulations are executed in the secondary
logical processor. Windows would multitask the applications test script in
the run queue of one logical processor where nothing else would be running,
while the synthetics would contend amongst themselves for attention in the
secondary logical processor. In a non-HT CPU, all of the tasks (whether real
or synthetic) would contend for timeslices within the same Windows' run
queue.
So given three simulated workloads and one real application load, when you
put the real application in its own logical processor, what you've
effectively done is given the application test-script a 3:1 priority
advantage over the synthetic workload simulations. In a non-HT CPU, all of
the threads go into the same Windows run queue, and they all get equal
priority according to the default task scheduling behaviour. Only the
real-world app test-script's elapsed time is ever recorded; the results of
the
simulated workloads are never measured and discarded, since they are only
there to add a simulated workload and therefore they are disposable.
Now, is this a good measure of a multitasking workload? Only if you consider
a proper use of multitasking to be running one real-world app in the
foreground while disposable workload simulators bog it down in the
background.
Okay those were just the technical faults about this benchmark. There's also
some conspiracy theory stuff here. One of the co-authors of this article,
Randall C. Kennedy, happens to be the designer of this benchmark:
http://www.csaresearch.com/about.asp
Mr. Kennedy was once an employee of Intel, according to the above biography:
"Later, as a contract testing and development engineer for Intel
Corporation, he led the effort to create tools and resources to articulate
the company's performance initiatives surround high-end desktops (Constant
Computing) and Gigabit Ethernet networking."
Which sounds like he worked in the benchmarketing department.
Furthermore, this guy is some sort of long-time crusader for Hyperthreading.
He's written articles favouring Hyperthreading for a long time now, this one
from about two years ago:
http://www.networkcomputing.com/1324/1324buzz2.html
Nothing wrong with being a crusader for the technology and showing to world
an example of an application that really benefits from Hyperthreading, just
so long as you don't try to pass that off as a benchmark.
Yousuf Khan
erformance options so it