[linux-help] Re: Dual processors

[Wayne White <WWHITE13@xxxxxxx>]

At 09:36 PM 8/10/2002 -0500, you wrote:

>On Sat, 10 Aug 2002, Lowell Premer wrote:
>
> > To a certain extent, this was the point to ny (regretably smart-assed
> > sounding) reply below; applications have to be written especially to take
> > advantage of dual-or-greater proceesing IIRC...I was wondering which of
> > the software being used in your case was dual-processor friendly...
>
>For a single application to see significant change in speed, it does have
>to be multi-threaded so it can run on multiple CPU's at the same time...
>and there aren't that many of those on the average user's desktop
>
>But you don't need multi-threaded processes to see large benefits from
>multiple CPU's... because you're running more than one program at a time.
>SETI@Home can have an entire CPU to itself while a second CPU runs
>everything else.  Nobody has to be multi-threaded for that.
>
>If they did, there wouldn't be a reason for the 6-cpu HP-UX boxes we run
>at work, because none of our applications are multi-threaded. On a
>single-CPU box, only one process can run at a time... and each process
>gets a tiny slice of CPU time every so often.  On a multi-CPU box, you can
>have as many processes running at the same time as you have CPU's... you
>double the number of tiny slices of CPU time available.
>
>Drop in a second CPU (and appropriate kernel config) and you'll see a
>performance increase immediately, no special software required.  If most
>of your applications are CPU-bound (they're waiting for more CPU time, not
>waiting to read/write data somewhere), you'll certainly see an increase in
>performance.
>
>Probably the best way to visualize what multiple CPU's do to performance
>is to run 'top' on a multi-CPU box that's running a lot of CPU-intensive
>stuff.
>
>_Now_, all that said, multiple CPU's won't do you a lot of good if you're
>box is like mine... sitting at 99% idle most of the time.  Obviously, if
>you have a lot of CPU white-space, you don't need another CPU.  Though you
>need to look at peak times and not averages... when things are the
>busiest, how much of that is CPU-bound programs and how long are programs
>waiting for their slice of the CPU time?  (In my case, most of my programs
>are IO-bound... apache, mysql, sendmail... stuff whose job is to push bits
>around instead of adding them up.)
>
>As an aside... if you fancy being a systems administrator, you don't
>_have_ to understand how the kernel works.  But if you _do_, it'll make
>your job a lot easier and your skills a lot more marketable.  And it'll
>keep you from doing things like promising the boss that a second CPU will
>speed up your applications when the problem is IO and not CPU. :)
>
>--
>Carl D Cravens (raven@xxxxxxxxxxx)
>If at first you don't succeed, try 2nd or shortstop.

Thanks Carl, your explanation is vastly better than mine.

wayne

-- This is the linux-help@xxxxxxxxx list.  To unsubscribe,
visit http://www.complete.org/cgi-bin/listargate-aclug.cgi