Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!unmvax!gatech!hubcap!dinucci From: dinucci@ogccse.ogc.edu (David C. DiNucci) Newsgroups: comp.parallel Subject: Re: "Molecule: Language Construct for Development Parallel Programs" Message-ID: <5613@hubcap.clemson.edu> Date: 26 May 89 11:59:31 GMT Sender: fpst@hubcap.clemson.edu Lines: 81 Approved: parallel@hubcap.clemson.edu In article <5606@hubcap.clemson.edu> John.Baugh@LINDENTHAL.CAE.RI.CMU.EDU writes: >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. Wow! Somebody has heard of Large-Grain Data Flow (LGDF)! Actually, back then, LGDF could only be ported to shared-memory multiprocessors. Since then, however, a few things have changed. My first goals when I came on board were to determine (1) what a REAL (i.e. formal) description of LGDF would look like, and (2) what features kept LGDF programs from being efficiently implemented on distributed-memory machines. Those goals led to an even deeper search: could both the shared memory model and the message passing model be considered special cases of one "more basic" model? The result has been LGDF2, and I believe the search has been fruitful. It comes down to this: both models consist of "processes" sharing information. Upon "accessing" some information, a process dictates the set of processes that are allowed to access it next. If each process knows what type of access it will make (reading, writing, neither, both) to the information if it runs, parallelism can be increased - for example, by allowing multiple readers to access information concurrently. In LGDF2, the programmer explicitly specifies the granularity of processes - we simply ensure that they share data in an efficient an uniform way regardless of the (MIMD) architecture they are executed on. In addition, we allow the programmer to specify non-deterministic computations. The most recent stuff on LGDF2 has been published in 1988 Proc. 21st Hawaii Int'l Conf. on System Sciences (DiNucci, Babb) Parallel Processing for Scientific Computing (Babb, DiNucci) (Actually 1987 Proc. 3rd SIAM Conf. on Par. Proc. for Sci. Computing) Digest of Papers, CompCon Spring 89 "Intellectual Leverage", (DiNucci, Babb) The last paper gives some hints on what we're working on now (including work on arrays which was sadly lacking in the above papers). Incidentally, the "Molecule" article was written in 87, and some other models have come to light since then. Chandy and Misra's UNITY comes to mind (see "Parallel Program Design - A Foundation", 1988, Addison-Wesley). >[more stuff deleted] > >In (???) Marshall Cline writes: >>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 Well, ours is. LGDF2 is now becoming a full-fledged language for building parallel programs (networks) from processes, leaving the role of constructing processes from statements to more standard language processors (though these processes need not need be sequential). We are finding that many "object-oriented" principles find a comfortable home at the higher LGDF2 level (resulting in screams of outrage at the idea of object- oriented Fortran programs). In fact, isn't the restricted, controlled sharing of information among computional agents one of the central tenets of software engineering, object-oriented or otherwise? > >[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 -- David C. DiNucci UUCP: ..ucbvax!tektronix!ogccse!dinucci Oregon Graduate Center CSNET: dinucci@cse.ogc.edu Beaverton, Oregon