[CentOS] maximum cpus/cores in CentOS 4.1

Lamar Owen lowen at pari.edu
Fri Sep 9 20:44:03 UTC 2005


[One final reply to Bryan before *PLONK* goes in here]

On Friday 09 September 2005 14:37, Bryan J. Smith wrote:
> Lamar Owen <lowen at pari.edu> 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



More information about the CentOS mailing list