Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!wuarchive!wugate!uunet!dg!chris
From: chris@dg.dg.com (Chris Moriondo)
Newsgroups: comp.arch
Subject: Re: ATTACK OF KILLER MICROS
Message-ID: <220@dg.dg.com>
Date: 18 Oct 89 22:50:29 GMT
References: <35825@lll-winken.LLNL.GOV> <1081@m3.mfci.UUCP> <35896@lll-winken.LLNL.GOV> <33798@ames.arc.nasa.gov> <35977@lll-winken.LLNL.GOV>
Reply-To: chris@dg.dg.com (Chris Moriondo)
Organization: Data General, Westboro, MA.
Lines: 33

In article <35977@lll-winken.LLNL.GOV> brooks@maddog.llnl.gov (Eugene Brooks) writes:
>This is the stuff of research papers right now, and rapid progress is being
>made in this area.  The key issue is not having the components which establish
>the interconnect cost much more than the microprocessors, their off chip
>caches, and their main memory.

The only really scalable interconnect schemes of which I am aware are
multistage interconnects which grow (N log N) as you linearly increase the
numbers of processors and memories.  So in the limit the machine is essentially
ALL INTERCONNECT NETWORK, which obviously costs more than the processors and
memories.  (Maybe this is what SUN means when they say "The Network IS the
computer"?  :-)  How do you build a shared-memory multi where the cost of the
interconnect scales linearly?  Obviously I am discounting busses, which don't
scale well past very small numbers of processors.


>We have been through message passing hypercubes and
>the like, which minimize hardware cost while maximizing programmer effort.
>I currently lean to scalable coherent cache systems which minimize programmer
>effort.

While message passing multicomputers maximize programmer effort in the sense
that they don't lend themselves to "dusty deck" programs, they have the
advantage that the interconnect costs scale linearly with the size machine.
They also present a clean programmer abstraction that presents the true cost
of operations to the programmer.  I read a paper by (I think) Larry Snyder
wherein he argued that the PRAM abstraction causes programmer to produce
suboptimal parallel algorithms by leading one to think that simple operations
have linear cost when in reality they can't be better than N log N.

chrism

-- Insert usual disclaimers here --