RE: Dual or Single CPU?

[Matt Drew <mdrew redhat com>]

>From my (subjective) experience:

The qualities that you gain from a dual-cpu system are quantifiable at
some level.  However, most of what I've seen is a lot more subjective
than that.

Dual CPU systems are useful longer than their single-CPU cousins, even
single CPUs that are quite a bit faster.  They are better able to deal
with OS load, especially on a system that handles multiple CPUs properly.  
This translates into a basic "my system seems to be snappy and responsive"
vibe because the system is better able to deal with two things at
once.  Most things don't require a lot of processor *speed*, but will eat
up cycles and interrupts for various reasons. A dual-CPU system is able to
keep doing things even if one CPU is occupied with something -- very
useful.

Remember that the measure of a system's "speed" (whatever that means) has
a lot to do with the motherboard and the basic system hardware -- and
dual-CPU motherboards tend to have the higher-end, faster supporting
hardware that has more "bandwidth" and is better able to deal with load.
They also tend to support more memory, which translates into a longer
useful life.  Think about a Pentium system with 32MB versus a Pentium
system with 512MB -- the latter is still useful for some things today,
while the former is only good as a router or basic client -- but how
many Pentium motherboards had support for 512MB?

Dual-CPU systems are usually the best price/performance/life-cycle systems
you can buy.  The sweet spot is about 3-5 months behind the bleeding-edge
curve.  For example, two Athlon 800's as opposed to a 1GHz single.  On
pricewatch.com, the 800's are $129, the 1GHz is $257, and the 1.2GHz is
$503!!!!  So for roughly the same price, you could have one 1.2GHz, two
1.0GHz, or four 800MHz.  Even including the price of the motherboard
(which spikes as you increase the number of processors due to
communications overhead and general system sophistication) the
price/performance advantage of multiple CPUs is very apparent.  Right now,
2-4 CPUs is best performance gain without getting freaky on price.

All of this is, of course, entirely dependent on the OS and the
applications.  With an app like distributed.net, you see basically a 100%
performance improvement, since it is specifically designed to run on
multiple processors almost indepedently. (My dual PIII550 does 1.5 Mkeys
on one CPU, and 3.0 Mkeys on two).  Apache, gcc, Photoshop, Lightwave, and
GIMP are all examples of applications that are (can be) specifically
optimized for 2-4 processors.  If you are working with any of those, two
CPUs are definitely better than one.  In general, if your application is
multi-threaded, you are in business.  Also if you are planning to run many
processes concurrently, two CPUs are definitely better than one (and more
memory is also much better).  A multi-threaded application handles it's
own CPU management, whereas the multiple processes are managed by the
kernel with varying results.

Linux is pretty good at SMP, especially in the 2-4 CPU range.  On average,
performance will increase fairly linearly up to four processors.  I look
at it this way -- I would rather spend the money on memory than on CPU at
this stage in the game.  A dual P3-800 with 512MB is a hell of a lot more
useful down the road than a 1.16Ghz P3 with 128MB.

The ONLY issue with dual-CPU systems is high-performance applications that
aren't suitably multi-threaded, for whatever reason -- in other words,
games.  Quake 3 is the only game that I know of with fairly robust support
for dual CPUs, and the performance gain is not that great.  Games tend to
be very tightly organized and to have specific speed optimizations that do
not lend themselves well to multiple CPUs.  In theory, one could design a
game optimized for two CPUs -- but that would slight single-CPU
performance, and the vast majority of the market is still single-CPU.  
However, since gamers are shelling out for a new video card every year
anyway, they tend to also shell out for a new system -- price is a
secondary (albeit important) concern in most cases.


The last area to consider is upgrading.  If you time your purchase right
and get a good dual system with processors towards the lower end of the
motherboard's support range, you can generally upgrade a year or two years
down the road for a very small cost -- and get a large performance boost.  
For example, if I were to replace my 800s with 1.2's a year or two years
from now, I bump my system back into the sweet spot for a fraction of the
cost of an entirely new system (which would be required for a 1.2GHz to
2.0GHz upgrade -- new motherboard, new case, new memory).  CPU power
generally doubles every 18 months, right?  However, the supporting
structure (motherboards, memory, etc) generally don't follow that pattern.  
New motherboards and memory tend to cost *a lot*, while older memory is
cheap and plentiful.  Also, the supporting structure tends to move in
leaps when it can no longer support the newest processor technology,
resulting in a window of opportunity that you can exploit to get the most
bang for your buck.

my $10.47 :)

Matt


 On Fri, 27 Oct 2000, Dan Cuthbert wrote:

> Okay ill have to admit, i have done a fair amount of testing being based
> where i am!
> SMP servers do work faster and handle better loads over their single
> cousins, but for the "average" use he wont be able to utilise them enough to
> notice a difference!
> 
> i run a Dell poweredge using Dual 500mhz's (okay im Running FreeBSD..but..)
> and that handles the load i place on it (kernel compiles all day long and
> other heavy duty compiling
> 
> plus im running dualhead and have two instances of E running so they both
> take 1 cpu and balance the load
> 
> At the end of the day, a decent single cpu will do most people well
> 
> Dan Cuthbert
> European Hosting Research & Engineering
> PSINet Datacentres
> mobile: +44 77 1279 0646
> 
> -----Original Message-----
> From: redhat-install-list-admin redhat com
> [mailto:redhat-install-list-admin redhat com]On Behalf Of Colin J. Raven
> Sent: 27 October 2000 16:52
> To: redhat-install-list redhat com
> Subject: RE: Dual or Single CPU?
> 
> 
> OK, let me take a moment to clarify the "why" here, just so that you folks
> know; "where I'm coming from" on this project. It's not a hobbyist's dream
> (well, I guess it is in a way) but has more serious overtones.......
> 
> This is a "proof of concept" exercise that I have undertaken on behalf of my
> company. I gave up smoking, so I decided to buy myself a present using the
> equivalent amount 'o cash that I would have seen go up in smoke and do the
> project as a personal learning exercise.
> 
> I too wondered about the single/dual cpu question. In truth I always wanted
> to see what a dual cpu  fire breathing monster would feel like...(yeah, I
> know...F.A.S.T) so in ths case it was a real dilemma believe me. It was
> exactly as you wrote...one top 'o the line cpu...or two? I punked out when
> the dollars climbed, and although I *could* have squeezed just a little more
> into this project, I was shellshocked enough to call it quits. Essentially I
> figured that I probably needed more memory as opposed to CPU cycles, since
> this machine will probably never see a graphics program, and I am unlikely
> to be cruching 1 million record database queries.
> 
> So, I'm interested in this thread too. It's not too late to change to a dual
> cpu config if there is a consensus that *that* setup would deliver a
> "better" result. (The VMWare/Win side will be doing significant Access small
> database work, so maybe there really is a clock cycle issue here, but I
> thought that a Xeon chip would have the architecture [stamina? "Right
> Stuff"?] to do the job. The darned machine will take up to 2GB of RAM as
> well as a second CPU, so my options going forward are fairly wide open I
> think.
> 
> This was just for clarification, that's all.
> 
> Regards to all, and thanks for the many suggestions that have flowed this
> way so far...and my guess is that we're far from finished yet.
> 
> -Colin
> --
> Colin J. Raven
> 
> >-----Original Message-----
> >From: redhat-install-list-admin redhat com
> >[mailto:redhat-install-list-admin redhat com]On Behalf Of Rob Toner
> >Sent: Friday, October 27, 2000 11:14 AM
> >To: redhat-install-list redhat com
> >Subject: Re: Dual or Single CPU?
> >
> >
> >"C. Bryan Young" wrote:
> >
> >> This is sort of related to Colin's earlier post -- regarding the
> >specs for
> >> his new workstation.  I'm just curious whether -- for the same
> >price -- it
> >> is better to get 1 top-of-the-line cpu (in his case a 933MHz Xeon) or 2
> >> lesser cpus (say, PIII 800 MHz).
> >>
> >> I know this depends on intended application.  Let's say one wanted to run
> >> dual OS's using VMWare.  I would tend to think that dual cpu's would be
> >> better, but don't know enough about smp -- especially in Linux -- to know
> >> for sure.
> >>
> >> Any thoughts?  I'm just curious -- want to learn more about smp in Linux.
> >>
> >> --Bryan
> >>
> >> -----Original Message-----
> >> From: Jeff Lane [mailto:jlane redhat com]
> >> Sent: Friday, October 27, 2000 9:23 AM
> >> To: redhat-install-list redhat com
> >> Subject: RE: RedHat 7.0 and Matrox G400 compatibility
> >>
> >> On Fri, 27 Oct 2000, Colin J. Raven wrote:
> >>
> >> > Anyone from RedHat care to comment on this one?
> >> > There's a $5500 workstation on hold until we can successfully
> >resolve this
> >> > issue.
> >> > Regards,
> >> > -Colin
> >>
> >> Hey... read my other posts... <grin>
> >>
> >> I have the Precision 420 here wiht the 32 MEg G400.  the original mga
> >> driver didnt work too well with the card.  I was forced to use X
> >> 3.3.6.  there is a new driver
> >> http://www.matrox.com/mga/support/drivers/files/linux_03.cfm here!!
> >>
> >> I found it!!!
> >>
> >> from the matrox site:
> >> This driver is based on the open source development being done within the
> >> XFree86 Project. The driver remains unmodified, with the exception of the
> >> display adapter initialization, which has been replaced with a closed
> >> source Matrox library. This special library enables features such as
> >> DualHead, TV out, and support for digital flat panel monitors.
> >>
> >> The readme included instructions for gettiung DRI and multihead
> >working as
> >> well.
> >>
> >> I feel much better now that i have found htat driver again.
> >>
> >> cheers
> >>
> >>  --
> >> (-0-)  (-0-)  (-0-)  <-0->  (-0-)  (-0-)  (-0-)
> >> Jeffrey D Lane
> >> Geek, Star Wars Fanatic, and collector of
> >> obselete technologies.
> >>
> >> 2600 Meridian Parkway   (919) 547-0012x168
> >> Durham, NC 27713        (888) REDHAT1x168
> >>
> >> "I propose that every city have a telephone
> >> number 119 -- for dyslexics> who have an
> >> emergency." -George W. Bush
> >> (-0-)  (-0-)  (-0-)  <-0->  (-0-)  (-0-)  (-0-)
> >>
> >> _______________________________________________
> >> Redhat-install-list mailing list
> >> Redhat-install-list redhat com
> >> https://listman.redhat.com/mailman/listinfo/redhat-install-list
> >>
> >> _______________________________________________
> >> Redhat-install-list mailing list
> >> Redhat-install-list redhat com
> >> https://listman.redhat.com/mailman/listinfo/redhat-install-list
> >
> >If you go with dual, lets say two 500 you get almost the same as
> >one 1gig.  Of
> >course the price is a little cheaper.  The main thing is you get
> >smp.  VMWare
> >you take a large hit on performance, but if you must, then go for it.  It
> >really depends on the app that your running.  RH supports SMP but
> >if the app
> >doesn't then there isn't any gain (for that app).
> >
> >
> >
> >
> >_______________________________________________
> >Redhat-install-list mailing list
> >Redhat-install-list redhat com
> >https://listman.redhat.com/mailman/listinfo/redhat-install-list
> >
> 
> 
> 
> _______________________________________________
> Redhat-install-list mailing list
> Redhat-install-list redhat com
> https://listman.redhat.com/mailman/listinfo/redhat-install-list
> 
> 
> 
> _______________________________________________
> Redhat-install-list mailing list
> Redhat-install-list redhat com
> https://listman.redhat.com/mailman/listinfo/redhat-install-list
> 

-- 
Matt Drew
Red Hat Consumer Services (Web Support)