Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!gatech!purdue!decwrl!decvax!ima!esegue!compilers-sender
From: eric@snark.uu.net (Eric S. Raymond)
Newsgroups: comp.compilers
Subject: Re: compiling for parallel machines
Message-ID: <1989Aug6.113745.309@esegue.uucp>
Date: 6 Aug 89 11:37:45 GMT
Sender: compilers-sender@esegue.uucp
Reply-To: eric@snark.uu.net (Eric S. Raymond)
Organization: Compilers Central
Lines: 29
Approved: compilers@esegue.segue.bos.ma.us

In <1989Aug4.180349.3480@esegue.uucp> Deb Banerjee wrote:
> Your suspicion about software rather than hardware being the challenge in
> parallel programming systems may be correct.

I would have thought this was obvious!

There's been enough theory done on network topology, relationships between
complexity (in the automata-theory sense) and various resource/transaction
costs, and multiprocessor scaling laws that the area can be described as
`mature'. Empirically, parallel-processing architectures have been
*converging* into a few broad families over the last three years rather than
*diverging*, a sure sign that researchers in the hardware end of the problem
now have a shared paradigm (in Thomas Kuhn's sense).

The software end is nowhere near this well-evolved. There are formalisms
like CSP that allow us to discuss the behavior of parallel systems in a
rigorous way, but no one has even come up with a convincing general attack on
the higher-level problem -- automatic parallelization of algorithms expressed
for a uniprocessor abstract machine in real languages (i.e. in the presence
of multiple assignment, side-effects and data aliasing).

There is the really *hard* problem!
-- 
      Eric S. Raymond = eric@snark.uu.net    (mad mastermind of TMN-Netnews)
-- 
--
Send compilers articles to compilers@ima.isc.com or, perhaps, Levine@YALE.EDU
{ decvax | harvard | yale | bbn }!ima.  Meta-mail to ima!compilers-request.
Please send responses to the author of the message, not the poster.