[One final reply to Bryan before *PLONK* goes in here]
On Friday 09 September 2005 14:37, Bryan J. Smith wrote:
> Lamar Owen <lowen@xxxxxxxx> wrote:
> > Since the Xeon will likely perform worse than an equivalent
> > speed Opteron, this is a valid comparison, and it has
> > nothing to do with interconnect.
> ??? What world do you live in ???
The world that shows that, if 3 is less than 4, then 3 is also less than 10.
If the E6500 performs worse than a Xeon, then it will also perform worse than
an Opteron. Simple enough for a child, yet it escapes you.
> They are _completely_ different.
No, they are not completely different. Last time I checked, they both
executed instructions, they both used RAM to store those instructions, and
they behaved as a Von Neumann machine. They are only different in the
details that you wish to emphasize.
> GTL+ and NUMA/HyperTransport are _completely_ different.
Xeon != GTL+ and Opteron != HT. GTL+ and HT are merely the interconnect,
which, while it very much does impact the performance of a box, it is just
the interconnect; having a different interconnect does not make two CPU's
_completely_ different, and you should know that. Is aluminum _completely_
different from steel?
> > yet, since I have no Opterons here
> Yes, that was pretty obvious.
Why don't you donate one? :-)
> > I was very pleased at the donated E6500's performance.
> Yes, because you compared it to Xeon. But you were doing it
> in the context of what the performance versus Opteron would
> be. It's wholly inapplicable.
The thread was about number of CPUs; I answered in a fashion that indicated
that I knew that this was only indirectly applicable (but since when have you
paid attention to what someone actually said?). I did a comparison that cast
the E6500 (a five year old box) against a decent server (by today's
standards) (BTW: not running x86_64 code, either, but i386 code) in a pretty
decent light. I made a fairly simple comment that you have blown completely
out of proportion, and you have made this worse than useless. You have told
me nothing I did not already know, other than that doing a *PLONK* on your
incoming e-mail to my servers would be a Big Win.
> > There are other reasons, not the least of which is that
> > SPARC is difficult to get increased clock speeds (hardware
> > contexts, IIRC).
>
> Don't even look at clock speeds. They are not comparable
> between _any_ platforms, much less have _nothing_ to do with
> most server operations. Interconnect is everything when it
> comes to the ability to move data.
You once again fail to read what I wrote. The UltraSPARC CPU (not
interconnect) architecture is difficult to get to run at higher clock speeds.
The Opteron, both by being lower cost at a given speed (and speed does
matter, even though raw clock speed doesn't matter as much as many think;
speed is a big factor for number crunching) outclasses the SPARC systems
these days. Economic reasons as much as any other probably played a
significant role here, and I personally do not agree that interconnect
technology was the major factor. Of course, a statement to the contrary by
someone in Sun who helped make that decision would prove me wrong.
> Other HyperTransport implementations -- e.g., AMD Opteron --
> use HyperTransport via NUMA, and their performance varies
> wildly on the ability of the OS to handle processor affinity
> for programs and I/O. It is very, very, _very_ different
> from the standpoint of system management, even if the
> firmware/logic allows transparent use of older, non-affinity
> or only "affinity hinting" OSes to utilize it.
The Sun Starfire and Gigaplane architectures both are impacted by
processor-RAM affinity, since access to the local RAM on any given CPU/memory
card is via the local UPA and doesn't have to hit the board-external
interconnect. In a manner of speaking, Gigaplane is a type of NUMA, even
though it isn't 'true' NUMA. Starfire OTOH can be true NUMA (the
architecture came from SGI). Don't bother to 'correct' me (I know I'm being
somewhat generic in those statements, and, if I had time and wanted to do so,
I could delve into the nitty-gritty); I won't see your reply.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
(828)862-5554
www.pari.edu
