🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #2684

Re: ATTACK OF KILLER MICROS

#2684
From: Terry Ingoldsby
Date: Wed, 18 Oct 1989 18:24
59 lines
3665 bytes
In article <MCCALPIN.89Oct16141656@masig3.ocean.fsu.edu>, mccalpin@masig3.ocean.fsu.edu (John D. McCalpin) writes:
> In article <35896@lll-winken.LLNL.GOV> brooks@maddog.llnl.gov (Eugene
> Brooks) writes:
> 
> >Microprocessor development is not ignoring vectorizable workloads.  The
> >latest have fully pipeline floating point and are capable of pipelining
...
> It seems to me that the experience in the industry is that
> general-purpose processors are not usually very effective in
> parallel-processing applications.  There is certainly no guarantee
> that the uniprocessors which are successful in the market will be
> well-suited to the parallel supercomputer market -- which is not
> likely to be a big enough market segment to have any control over what
> processors are built....

Agreed.  The only general purpose systems that I am aware of that exploit
parallel processing do so through specialized processors to handle certain
functions (eg. matrix multipliers, I/O processors) or have a small (< 16)
number of general purpose processors.
> 
> The larger chip vendors are paying more attention to parallelism now,
> but it appears to be in the context of 2-4 processor parallelism.  It
> is not likely to be possible to make these chips work together in
> configurations of 1000's with the application of "glue" chips....

It doesn't seem to be just a case of using custom designed chips as
opposed to generic glue.  The problem is fundamentally one of designing
a system that allows the problem to be divided across many processors
AND (this is the tricky part) that provides an efficient communication
path between the sub-components of the problem.  In the general case
this may not be possible.  Note that mother nature hasn't been able to
do it (eg. the human brain isn't very good at arithmetic, but for other
applications its stupendous).
> 
> This is not to mention the fact that software technology for these
> parallel supercomputers is depressingly immature.  I think traditional
> moderately parallel machines (e.g. Cray Y/MP-8) will be able to handle
> existing scientific workloads better than 1000-processor parallel
> machines for quite some time....
> --
I don't think we should berate ourselves about the techniques available
for splitting workloads.  No one has ever proved that such an activity
is even possible for most problems (at a *large* scale).  The activities
that are amenable to parallel processing (eg. image processing, computer
vision) will probably only be feasible on architectures specifically
designed for those functions.

Note that I'm not saying to give up on parallel processing; on the contrary
I believe that it is the only way to do certain activities.  I am saying
that the notion of a general purpose massively parallel architecture that
efficiently executes all kinds of algorithms is probably a naive and
simplistic view of the world.



-- 
  Terry Ingoldsby                       ctycal!ingoldsb@calgary.UUCP
  Land Information Systems                           or
  The City of Calgary         ...{alberta,ubc-cs,utai}!calgary!ctycal!ingoldsb
Technical Details
Message-ID: <490@ctycal.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!ubc-cs!alberta!calgary!ctycal!ingoldsb
References: <35825@lll-winken.LLNL.GOV> <1081@m3.mfci.UUCP> <MCCALPIN.89Oct16141656@masig3.ocean.fsu.edu>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!ubc-cs!alberta!calgary!ctycal!ingoldsb
From: ingoldsb@ctycal.UUCP (Terry Ingoldsby)
Newsgroups: comp.arch
Subject: Re: ATTACK OF KILLER MICROS
Message-ID: <490@ctycal.UUCP>
Date: 18 Oct 89 18:24:39 GMT
References: <35825@lll-winken.LLNL.GOV> <1081@m3.mfci.UUCP> <MCCALPIN.89Oct16141656@masig3.ocean.fsu.edu>
Organization: The City of Calgary, Ab
Lines: 59
Summary: Large scale parallelism unsuccessful in general cases