🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #13079

Re: Hypercubes and second note: (Parallel processing biblio)

#13079
From: pase
Date: Tue, 24 Feb 1987 19:24
44 lines
3359 bytes
In article <ulowell.1081> miner@ulowell.cs.ulowell.edu (Richard Miner) writes:
>You would not want a language that abstracted away the parallelism, what
>we need to develop are languages that model the parallelism of these new
>architectures.  As far as I am concerned most of the recently accepted
>languages (Pascal, Modula-2, Ada) are no better then FORTRAN(1) for 
>implementing algorithms on these machines.  We need to develop better
>languages based on parallel and data flow concepts to model these 
>architectures.

(1)	Agreed, FORTRAN, Ada, Pascal, Modula-2, etc. are not well suited
for parallel processing of any sort.  Kuck and his associates have done some
very good work on parallelizing these languages as much as can be done, but
many will agree that it is difficult and mostly ad hoc.

(2)	Occam and other languages of that class allow the free expression of
parallelism, but have the disadvantages that a) the programmer is responsible
for the placement of processes, and b) therefore the placement cannot change
to adapt to the requirements of the system.

	This is a disadvantage for several reasons.  Optimal static allocation
of tasks to processors is well known to be NP complete.  It is very difficult
even for small problems.  It assumes advance knowledge of the communication,
memory and CPU requirements, much of which is not available for any but the
most regular applications (eg. matrix operations, FFTs, etc.).  The allocation
must be recomputed any time there is a change in the network.  There is no
fault tolerance to any such system.  If a processor goes down, too bad.  The
computation must be restarted from the last save-point, but only after the
system has been fixed.  There is no way to run on a partial system.

(3)	Dataflow languages offer a clean alternative which is easy to
learn and simple to use.  They are best suited for dataflow architectures,
but could be used to some advantage on more conventional architectures.
This is a promising area.

(4)	Other languages - LML, &c. - allow the free expression of parallelism
but do not require a parallel computation model.  These are the languages
which "abstract the parallelism away".  They could execute equally well on a
uniprocessor or a multiprocessor system.  There are no explicit task
partitioning or communication mechanisms.  These languages, when combined with
dynamic load balancing techniques, allow algorithms to be expressed naturally
with no fuss over the underlying hardware.  Fault tolerance is also possible,
though I won't go into that here.
-- 
Doug Pase   --   ...ucbvax!tektronix!ogcvax!pase   or   pase@Oregon-Grad
Technical Details
Message-ID: <1212@ogcvax.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!water!watnot!watmath!clyde!rutgers!husc6!seismo!vrdxhq!verdix!ogcvax!pase
References: <76700001@uiucdcsp> <uiucdcsp.76700002> <1206@ogcvax.UUCP> <347@ames.UUCP> <1824@cit-vax.Caltech.Edu> <ulowell.1081>

Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: arc1-ca.pugleaf.net!utzoo!utgpu!water!watnot!watmath!clyde!rutgers!husc6!seismo!vrdxhq!verdix!ogcvax!pase
From: pase@ogcvax.UUCP
Newsgroups: comp.arch
Subject: Re: Hypercubes and second note: (Parallel processing biblio)
Message-ID: <1212@ogcvax.UUCP>
Date: Tue, 24-Feb-87 14:24:16 EST
Article-I.D.: ogcvax.1212
Posted: Tue Feb 24 14:24:16 1987
Date-Received: Fri, 27-Feb-87 23:39:10 EST
References: <76700001@uiucdcsp> <uiucdcsp.76700002> <1206@ogcvax.UUCP> <347@ames.UUCP> <1824@cit-vax.Caltech.Edu> <ulowell.1081>
Reply-To: pase@ogcvax.UUCP (Douglas M. Pase)
Organization: Oregon Graduate Center, Beaverton, OR
Lines: 44