Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: $Revision: 1.6.2.16 $; site ima.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!harvard!talcott!panda!genrad!mit-eddie!think!ima!johnl
From: johnl@ima.UUCP
Newsgroups: net.arch
Subject: Re: I don't believe your statements abou
Message-ID: <36900002@ima.UUCP>
Date: Thu, 9-May-85 11:11:00 EDT
Article-I.D.: ima.36900002
Posted: Thu May  9 11:11:00 1985
Date-Received: Sun, 12-May-85 01:51:03 EDT
References: <7202@Glacier.UUCP>
Lines: 33
Nf-ID: #R:Glacier:-720200:ima:36900002:000:1920
Nf-From: ima!johnl    May  9 11:11:00 1985


Has anybody ever claimed there was any advantage to multiprocessors other than 
price or (at the high end) constructability?  If so, I don't believe them 
either.  We now have about 40 years experience in programming uniprocessors 
and, relatively speaking, none in multiprocessors (unless you want to count APL 
and its relatives as implicitly programming multiprocessors.)  That's a lot of 
catching up to do even if programming parallel computers was as easy as 
programming serial processors, which it isn't.  

(Historical note: the Eniac was programmed as a bunch of autonomous 
communicating processors, and everybody agreed that the programming was a 
disaster.  In some cases, the Eniac was slower than the mechanical Mark I 
because for a given problem, the Mark I took 3 minutes to program and 10 to run 
a problem, while the Eniac took 15 to program but only 2 seconds to run.  Only 
Von Neumann's idea of central control made it possible to write interestingly 
large programs.) 

I keep seeing multiprocessors announced with great fanfare and then hearing 
nothing interesting afterward.  Hmmn.  The only place I can see where they 
might be useful would be in a busy transaction system, e.g. an airline 
reservation system, where having lots of processors for lots of transactions 
could win relative to context switching one or two large processors, which is 
what they actually do.

Finally, one interesting multiprocessor effort you might look at is the ELI 
project at Yale, as described in the paper by Ficher et al.  at the 1984 
compiler construction conference.  Their approach, though, is to have a large 
parallel asymmetrical machine with one hugely wide instruction stream 
controlling all of the parts, a far cry from the microprocessor jungles usually 
promoted.  

John Levine, Javelin Software, Cambridge MA 617-494-1400
{ decvax!cca | think | ihnp4 | cbosgd }!ima!johnl, Levine@YALE.ARPA