Xref: utzoo comp.sys.pyramid:360 comp.sys.sequent:215
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!decwrl!ucbvax!tut.cis.ohio-state.edu!unmvax!polyslo!cquenel
From: cquenel@polyslo.CalPoly.EDU (48 more school days)
Newsgroups: comp.sys.pyramid,comp.sys.sequent
Subject: Re: Questions about Pyramid/Sequent
Keywords: pyramid sequent
Message-ID: <9903@polyslo.CalPoly.EDU>
Date: 31 Mar 89 08:25:26 GMT
References: <764@sactoh0.UUCP> <404@sequoia.UUCP> <63984@pyramid.pyramid.com> <13305@sequent.UUCP>
Reply-To: cquenel@polyslo.CalPoly.EDU (48 more school days)
Distribution: na
Organization: Blue Blaze Irregulars
Lines: 60

The point I always have to make whenever this comes up:

Suppose for the sake of argument you have a single processor
machine on one side and an 8 processor machine on the other side
with each processor exactly equal to 1/8 of the larger CPU.
Suppose the prices and total performances are equal.

My argument is that the mono-processor machine is more flexible
because any process can chew on the while machine whenever/however
it wants.

I also claim that when the number of users is reasonably greater
than 8, then it will be difficult to tell which machine you're
using.  I have equated number of users with number of active
processes here.  It is possible for one user to have 5 active
processes (by "thinking parallel" :-) ) and it is possible to have 8
users and have only 5 active processes.

I seem to hear some advocates of multi-processors using the old
"gee it's neat when I've got all those processors to myself"
argument, but I don't think this is a valid argument for a
good general-purpose machine.

If you are considering a working environment where there 
are more processors than your average number of active 
processes most of the time, then you would actually be better off
with a mono-processor.  Think about it.

I have an 8 processor machine and I've spawned 7 processes.
I'm only using 7/8 of the machine.  If I were on the mono-processor,
I'd be using 8/8 of the machine, and (!) all my tasks would
finish sooner.  Even though I was sharing.

It all boils down to this:

	The burden of proof is on the multi-processing
	manufacturer.  They have to prove they can offer
	enough MORE bang/buck to counter act any difficulties
	introduced by multiprocessing.

In a heavy multi-user environment where the number of active
processes is almost always greater than the number of processors,
and you don't have any single process taking up the majority
of the machine's resources, then a multi-CPU machine will
work very much the same way as a mono-processor machine.

If you have a heavy number crunching grind-it-out program,
then you will have to "parallelize" it in order to take
advantage of any potential bang/buck advantage in a multi-CPU
system.

Anyway, enough for now.

--chris
"Virtual" means never knowing where your next byte is coming from.
-- 
@---@  ------------------------------------------------------------------  @---@
\. ./  | Chris Quenelle (The First Lab Rat) cquenel@polyslo.calpoly.edu |  \. ./
 \ /   |                   Better Red than dead !                       |   \ / 
==o==  ------------------------------------------------------------------  ==o==