Xref: utzoo comp.sys.pyramid:358 comp.sys.sequent:207
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!lll-lcc!lll-winken!uunet!tektronix!sequent!roc
From: roc@sequent.UUCP (Ron Christian)
Newsgroups: comp.sys.pyramid,comp.sys.sequent
Subject: Re: Questions about Pyramid/Sequent
Keywords: pyramid sequent
Message-ID: <13305@sequent.UUCP>
Date: 27 Mar 89 18:25:02 GMT
References: <764@sactoh0.UUCP> <404@sequoia.UUCP> <63984@pyramid.pyramid.com>
Reply-To: roc@crg2.UUCP (Ron Christian)
Distribution: na
Organization: Sequent Computer Systems, Inc
Lines: 50

In article <63984@pyramid.pyramid.com> csg@pyramid.pyramid.com (Carl S. Gutekunst) writes:
>The other side is that there simply are applications where you need to have
>that large CPU. Many problems simply can't be broken down and spread across
>multiple processors. And when users are running really parallel stuff, you
>can as solidly kill a multi-CPU machine well as its single CPU breatheren.

>Then there's the night-owls like me, who expect the machine to be damn fast
>when there's no one else on it.

Yeah, me too.  For me, that's a holdover from the old Vax days, where
you could get decent response only if you waited until 9:00 P.M. or so
to do your stuff.

On the Sequent machine, I got used to "thinking parallel", spawning
background processes with reckless abandon.  But occasionally, I
needed a single process to finish quickly, and you're right, the
machine just isn't "damn fast" when only one task is addressed.

And yet...  The Vax 11/750 (later 780) on which I cut my Unix teeth
is noticeably slower than a single i386 with reasonable support.
A single process on the Symmetry *does* go faster than what I used
to see late at night on the old machines.  It's just that I now
expect more, I guess.

Perhaps the late, lamented Cydrome had the right idea after all:  A
bunch of micros in parallel, and a very fast vector processor that
they could dip into as necessary.  I guess we'll never know, now.
:-(

The largest advantage, in my opinion, of having a lot of smaller
processors, as opposed to a few large ones, is consistency of 
response.  Regular users (as opposed to us "power users") expect
a task to always take the same amount of time and are thrown off
by the variation in response one sees on your typical uniprocessor
machine.  The most consistent response (assuming wide variation in
number of tasks) is with a large number of processors.  The best
bang for the buck whilst meeting the first objective is to provide
a large number of small processors.  Then, if a processor isn't being
used much, you haven't wasted much of your investment.

But your point is legitimate.  Sometimes a task just can't be parallelized.
And sometimes a 386 just isn't fast enough.

[It feels good to be participating in comp.sys.sequent again.  I was
out for awhile due to interviewing, and finishing up at Fujitsu, and
moving to Beaverton, but things have quieted down now.]



				Ron