Hello, been a while, dual CPU mobos

[Christopher Browne]

>  > This begs the question of what you expect your actual
>  > performance bottlenecks to be.
> 
> Well, it's not always about bottlenecks you know... sometimes a bigger
> hammer doesn't help you solve a problem nearly as fast as a bunch of
> smaller hammers. It depends on the nature of the problem.

No, it is _always_ all about bottlenecks.

It is _guaranteed_ that some component of the system will constrain
performance of the application.

Maybe it's the CPU(s), maybe you'll get hurt by memory bandwidth.  Maybe
disk bandwidth.  Perhaps network bandwidth, or latency.  For GUIed
applications, the "performance bottleneck" is likely to be the idiot at
the keyboard :-).

If the bottleneck isn't the CPU, then increasing the number of CPUs
won't help performance, plain and simple.

>> I would find it very surprising for you to need only pedestrian disk
>> and memory but find "premium" CPU hardware of use...

> Be surprised. The way I work, I find that an extra arm comes in handy
> more frequently than one realizes. Especially where clustering comes
> in to play. I'm not a windows user, ya know ;)

The economy of things normally is that if you have a system with a mere
512MB of RAM, it is almost certain that spending a couple hundred
dollars to upgrade to 2GB of RAM will provide the cheapest and most
effective performance upgrade.

After that, it's likely that throwing in a $200 cacheing RAID controller
and a few disk drives will be the next best upgrade.

Heading on to SMP is the _third_ option, after the earlier cheaper ones.

I find it _very_ surprising that extra CPU bandwidth is more compelling
than memory or disk I/O bandwidth.  Doubly so in that adding more CPUs
makes the system readily able to chew up _more_ memory and disk I/O and
network bandwidth.

If you step up from 1 to 4 CPUs, that means running 4x as much code,
accessing 4x as much memory, and having 4x as much data to throw at
disks and NICs.

We've got quad-Xeon boxes at work that actually start to _slow down_ as
you scale up assortedly because:

  a) Hyperthreading pretty much just sucks;
  b) Context switches get _way_ more expensive when you break the
     2GB barrier, which means that the last 6GB of memory on these
     boxes actually _slow_ performance, despite the stunning cost
     of the DIMMs :-(

The big, big win with AMD-64 is _not_ primarily in the ability to have
more CPUs, although it looks like it's no slouch there; the win is that
you can address 32GB of RAM without the performance-destroying hackery
of the Intel Xeons.
--
let name="cbbrowne" and tld="acm.org" in name ^ "@" ^ tld;;
http://www.ntlug.org/~cbbrowne/sgml.html
Rules of the Evil Overlord #25.  "No matter how well it would perform,
I  will never  construct any  sort  of machinery  which is  completely
indestructible  except  for   one  small  and  virtually  inaccessible
vulnerable spot." <http://www.eviloverlord.com/>
--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml