Questions about Pyramid/Sequent

[Richard Wood]

Cquenel at polyslo.CalPoly.EDU (48 more school days) writes:
> 
> 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.

    If your premises listed above were true, then much of your
    arguement below would be true as well.  The significant error is to
    assume that a single CPU machine and a multiprocessor (with
    equivalent amounts of aggregate power) would have the same price.
    If all other design elements were pretty much the same, the
    multiprocessor should cost less.

    What are the arguments for the multiprocessor costing more?
    Significantly more complex design, with caches, probably a faster
    bus.  On the other hand, the single CPU would have to be built with
    technology that is substantially more complex than the eight.  For
    instance, today's '386 chips can be designed very easily to get 3
    or so MIPS of power (more with a more expensive design).  You can't
    get a '386 running 24 MIPS (eight times faster).  Theoretically,
    you could, if you built it out of ECL or something.  But that
    single CPU would no longer be a chip - it would now be a multichip
    design.  The cost of designing that board will be substantially
    higher than the cost of designing the basic CPU subsystem in the
    multiprocessor.  Even more importantly, the cost of manufacturing
    and servicing it would be very, very much higher.  A final, but
    certainly not insignificant detail, is that the multiprocessor is
    going to get to market *A LOT* faster, due to the simpler overall
    design.

    Admiral Grace Hopper (inventor of Cobol) likens it to a farmer
    that suddenly needs to plow a field twice as big as his ox can
    handle.  The single-CPU paradigm would have him buy an Ox that
    is genetically engineered to be twice as big, and twice as
    powerful.  The multiprocessor paradigm would argue for simply
    getting a second ox.  Any farmer could tell you which would be
    cheaper :-)

    The basic rationale is that it is cheaper to use off the shelf
    technologies as building blocks, instead of designing new
    processors for each and every generation.

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

    No one will argue with you.  A single source of cycles will
    always be able to allocate them with more flexibility.  This
    actually follows directly from queuing theory.

> 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.

    It actually happens (at least under Unix) even without
    "thinking parallel," although that does dramatically increase
    the flow.  Sit down at a single user workstation sometime and
    do a "ps ax | wc -l".  All the background stuff Unix does can
    take advantage of those "other" CPUs.  (I.e., my workstation
    has 45 processes listed, and I'm hardly doing anything - true,
    most of those will wait hours before seeing action).  A prime
    example is the inherent multiprocessing that is showing up in
    todays computing model.  The window I'm editing in right now
    taps several different processes, including the editor, the
    terminal emulator (wish I had xrn...), the X-Server process,
    some NFS daemons on my local machine, and some on the server
    somewhere else in the building.

> 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.

    Except, perhaps one should take into account the fact that the
    monprocessor is going to cost dramatically more, as explained
    above.  There is some "clumsiness" about using a multiprocessor
    in a non-parallel processing environment, but the cost payoff
    can be dramatic.  And

> 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.

    The  burden of proof should *always* be on the person trying to
    sell, regardless of what they're selling.  There are tradeoffs
    in every decision.  For this kind of purchasing problem, the
    questions are two:

	Do I have an environment that makes full use of multiple
	processors?  If no...
	Is the presumably decreased cost of the multiprocessor worth
	the loss of flexibility in how I use the 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.

There is another way that "heavy number crunching" programs can take
advantage of a multiprocessor:  concurrency.   Run multiple versions of
the same program simultaneously on different data sets.  This assumes
two things:  first, that there are different data sets that need to be
processed;  if you only have the need to run one simulation at any time,
for instance, then this wouldn't be the case.  Second, it assumes that
throughput is a reasonable substitute for response time.  If having ten
jobs done in ten minutes isn't as good as having one job done in one
minute, than the thumper (to use a motorcycling term) is the proper
tool.  [A thumper is a single cylinder engine; the obvious analogy is
left as an exercise for the reader]

-- ----------------------------------------------------------------------------
Does it need saying that I'm not speaking as an official representative of DEC?
===============================================================================
Richard Wood  !  U. S. Worksystems, Palo Alto  !  Digital Equipment Corporation