Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!hubcap!tseng
From: tseng@rice.edu (Chau-Wen Tseng)
Newsgroups: comp.parallel
Subject: Re: Justifications for || processing
Keywords: Parallel Processing, Parallelizing Compilers
Message-ID: <12357@hubcap.clemson.edu>
Date: 19 Dec 90 18:53:20 GMT
Sender: fpst@hubcap.clemson.edu
Reply-To: tseng@rice.edu (Chau-Wen Tseng)
Organization: Computer Science Dept, Rice University
Lines: 30
Approved: parallel@hubcap.clemson.edu

Michael Carter (carter@iastate.edu) writes:

> > On a related note, how prevalent are compilers that parallelize code?
>
> There are none.  Note that I do *NOT* call the MIMDizer a parallelizing
> compiler!  As far as I know, it only works for certain shared-memory by
> recognizing very specific constructs in FORTRAN. 

A distinction needs to be made between shared/distributed memory 
parallelizing compilers.  For shared memory computers, commercial
firms such as Stardent, Convex, IBM, KAP, Pacific Sierra, etc... 
all provide compilers to convert sequential Fortran into parallel
and/or vector code.  Many of these compilers were based on the 
pioneering work done at the Univ of Illinois and Rice.

For distributed memory computers, the state of the art is much less
advanced.  I know of at least two commercial parallelizing compilers: 
MIMDizer from Pacific Sierra and Aspar from ParaSoft.  The CM Fortran 
compiler from Thinking Machines Corp/Compass is close - it requires the 
programmer to specify the parallelism, but handles almost everything else.
In addition, there are a ton of universities tackling this problem.  They 
include groups working on Superb, Crystal, ParaScope, ID Nouveau, Kali, 
Dino, AL, Pandore, Paragon, Oxygen, Booster, Spot, and Parti, just to 
name a few :-)  


Chau-Wen Tseng
Dept of Computer Science
Rice University