Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!gatech!hubcap!John.Baugh
From: John.Baugh@LINDENTHAL.CAE.RI.CMU.EDU
Newsgroups: comp.parallel
Subject: Re: "Molecule: Language Construct for Development Parallel Programs"
Message-ID: <5606@hubcap.clemson.edu>
Date: 25 May 89 17:11:34 GMT
Sender: fpst@hubcap.clemson.edu
Lines: 62
Approved: parallel@hubcap.clemson.edu

In article <5593@hubcap.clemson.edu> cline@sunshine.ece.clarkson.edu 
(Marshall Cline) writes: [stuff deleted]
>taken care of by the next pre-processing step).  The "dataflow" programs
>are translated into this "mode" layer by a first pre-processing step.
>Programs at this level _do_ have individual processes specified (ie:
>decomposing the program into processes is accomplished by the "dataflow
>--> mode" preprocessor).  A generic form of IPC is also visible at
>this "mode" layer, which was hidden in the top-most layer.

On a related note, Robert Babb has apparently used FORTRAN + data
dependencies in a similar way to drive execution of programs (see
Computer, July '84).  He argues, I believe, that the resulting
programs can be mapped easily onto a variety of hardware 
architectures.

[more stuff deleted]

>QUESTION #4: Are parallel languages headed towards levels that are higher
>than what we now call "high level" languages?  Ie: Given that we are/will-be

The Arvind camp certainly promotes the non-strict dataflow approach
(e.g., I-structures), though at a fine-grain of parallelism, because
of its inherent determinacy and parallelism.

A problem that must be dealt with by such languages (i.e., functional,
dataflow, ...) is the incremental update of arrays.  Otherwise, many
common numerical algorithms become excessively space inefficient.
Take a look at Arvind's "Future Scientific Programming of Parallel
Machines," MITLCS Computation Structures Group Memo 272, Feb. '88.
The algorithm presented for Gauss elimination takes advantage of
I-structures, but creates a new array at each elimination step, the
size of which begins at NxN and is successively reduced to 1x1.  An
alternative to this, which I describe in my thesis, is the combination
of array comprehensions and algorithms like Crout reduction and
Choleski decomposition, which do not successively rewrite the values
of the resulting triangularized arrays.  This approach requires no
copying.

Of course there are other approaches to the incremental update
problem, and some are these are discussed in papers by Wadler and
Hudak in Proceedings of the Workshop of Graph Reduction, LNCS 279,
'86.  They basically recommend a variety of monolithic array
constructors.  Other approaches include reference counting to
determine whether an array can be destructively modified, and Wise
presents a quadtree implementation of matrices in IPL, May '85.

The bottom line seems to be that one needs non-strict arrays, various
(monolithic) array constructors, array comprehensions, etc., to be
able to describe numerical programs in a reasonable(?) way (in a
dataflow language).  I'm not sure how elegant the resulting programs
would be.  In addition, non-strict arrays, for example, also destroy
referential transparency (which I won't argue for or against).

[more deleted]

>	________________________________________________________________
>	Marshall P. Cline	ARPA:	cline@sun.soe.clarkson.edu
>	ECE Department		UseNet:	uunet!sun.soe.clarkson.edu!cline
>	Clarkson University	BitNet:	BH0W@CLUTX
>	Potsdam, NY  13676	AT&T:	(315) 268-6591

John Baugh