Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: 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> <1206@ogcvax.UUCP> <347@ames.UUCP> <1824@cit-vax.Caltech.Edu> Reply-To: pase@ogcvax.UUCP (Douglas M. Pase) Organization: Oregon Graduate Center, Beaverton, OR Lines: 44 In article 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