anand@elsa.top.cis.syr.edu (Rangachari Anand) (12/11/90)
Using a group of workstations connected on a LAN as a prallel computer is an idea that is continually being rediscovered. Given the high speeds of the available workstations, this is clearly an Idea Whose Time Has Come. Indeed, I think that such an arrangement is arguably at least the equal of dedicated parallel computers in speed for some problems and definitely very cost effective. I get the feeling however that there is considerable reluctance to work on coarse-grained parallel programs as they appear to be too simple. In my view a coarse-grained algorithm simply means that the number of possible methods implementation is simply greater. Anyway, I wonder if there is a survey about packages developed for this task. More to the point, it would be interesting to know the speeds obtained for specific problems. Here are a few systems that I am aware of: 1. At Caltech they used a group of workstations as a virtual hypercube. 2. One implementation of Linda runs on a group of workstations. 3. There seems to be some work at Brown University in distributing ray-tracing over workstations. 4. A package called AERO from Berkely. This was recently announced in comp.os.research. This seems to be a very nicely put togethere system. 5. Over the summer, I wrote a package which combines ISIS and C++ to simplify the creation of parallel programs. It is actually a compiler similar to Sun's rpcgen and is available for anonymous ftp from mach1.npac.syr.edu -- R. Anand anand@top.cis.syr.edu
feldy@CS.UCLA.EDU (Bob Felderman) (12/11/90)
In article <12179@hubcap.clemson.edu> anand@top.cis.syr.edu (Rangachari Anand) writes: >Using a group of workstations connected on a LAN as a prallel >computer is an idea that is continually being rediscovered. >Anyway, I wonder if there is a survey about packages developed >for this task. More to the point, it would be interesting to know the >speeds obtained for specific problems. I participated in a project at UCLA a few years ago which did this type of thing on a network of PC-ATs. One of the real challenges was dealing with DOS! The code was never released, but was used here at UCLA for several projects and a class. No one seems to be aware of out work, or maybe they aren't interested! >From looking around, I think we were one of the first to actually implement a system that allowed parallel processing. Many other systems just migrated single process tasks throughout the network. Here's the reference, it includes some performance analysis of two algorithms, a merge sort and parallel search (IDA*): R.E. Felderman, E.M. Schooler, L. Kleinrock The Benevolent Bandit Laboratory: A Testbed for Distributed Algorithms IEEE Journal on Selected Areas in Communications Vol 7, No. 2 February 1989 -- Bob Felderman feldy@cs.ucla.edu UCLA Computer Science ...!{rutgers,ucbvax}!cs.ucla.edu!feldy
jet@karazm.math.uh.edu (J. Eric Townsend) (12/11/90)
In article <12179@hubcap.clemson.edu> anand@top.cis.syr.edu (Rangachari Anand) writes: >1. At Caltech they used a group of workstations as a virtual hypercube. "Cosmic Environment" is available from CalTech, but I don't know what restrictions they place. (We have it here...) >3. There seems to be some work at Brown University in distributing >ray-tracing over workstations. CE uses iPSC-style calls (iPSC-os looks remarkably similar to CE in several places, what a coinkadink :-); so it should be no problem to port the irisa VM_pRay or whatever it's called over to a network of nodes. It would die a horrible flaming death, however, as it relies heavily on inter-node communications. I'm working on a parallel ray-tracer written in PC that (at this time) is *very* coarse-grained, that is, there is no processor-processor communication at all. :-) It runs under CE quite well. PC can be obtained from karazm.math.uh.edu(129.7.7.6):pub/Parallel/pc* -- J. Eric Townsend Internet: jet@uh.edu Bitnet: jet@UHOU Systems Mangler - UH Dept. of Mathematics - (713) 749-2120 Skate (UNIX || AmigaDos) "This meme's for you..."
gt4589b@prism.gatech.edu (Davis, Jr., Martin H.) (12/12/90)
In article <12190@hubcap.clemson.edu> feldy@CS.UCLA.EDU (Bob Felderman) writes: > >I participated in a project at UCLA a few years ago which did this type >of thing on a network of PC-ATs. One of the real challenges was dealing with >DOS! >The code was never released, but was used here at UCLA for several projects >and a class. No one seems to be aware of out work, or maybe they aren't >interested! > >Here's the reference, it includes some performance analysis of two algorithms, >a merge sort and parallel search (IDA*): > >R.E. Felderman, E.M. Schooler, L. Kleinrock >The Benevolent Bandit Laboratory: A Testbed for Distributed Algorithms >IEEE Journal on Selected Areas in Communications >Vol 7, No. 2 >February 1989 > I don't wish to seem impertinent, but I think the reason "No one seems to be aware of our work . . ." is because of the journal in which the article was published. Being in a Computer Science department myself, I don't believe I would have thought of looking in JSAC for such an article (though there are others types of articles I look in JSAC for). I'm sure you had a good reason for this subject's being pub- lished in JSAC, but that reason is not immediately obvious to me. --Martin Davis -- DAVIS,MARTIN HENRY JR Georgia Institute of Technology, Atlanta Georgia, 30332 uucp: ...!{allegra,amd,hplabs,seismo,ut-ngp}!gatech!prism!gt4589b ARPA: gt4589b@prism.gatech.edu
schooler@isi.edu. (12/12/90)
In article <12179@hubcap.clemson.edu, anand@elsa.top.cis.syr.edu (Rangachari Anand) writes: >Anyway, I wonder if there is a survey about packages developed >for this task. More to the point, it would be interesting to know the >speeds obtained for specific problems. Here are a few systems that I am >aware of: > ... > >3. There seems to be some work at Brown University in distributing >ray-tracing over workstations. The Apollo animation, "A long ray's journey into light", which appeared at SIGGRAPH '85, was made by distributed ray-tracing. Each frame was farmed out to an idle workstation on the net. I believe upwards of 100 machines were used to complete the work. The more humorous statistic was the number of hours in total this took; I seem to recall something like 8 or 10 thousand. The video includes these stats at the end of the film, which was only about 3 minutes in duration! In article <12190@hubcap.clemson.edu> feldy@cs.ucla.edu writes: >R.E. Felderman, E.M. Schooler, L. Kleinrock >The Benevolent Bandit Laboratory: A Testbed for Distributed Algorithms >IEEE Journal on Selected Areas in Communications >Vol 7, No. 2 >February 1989 AND In article <12205@hubcap.clemson.edu> gt4589b@prism.gatech.edu (Davis, Jr., Martin H.) writes: >I don't believe I would have thought of looking in JSAC for such an >article (though there are others types of articles I look in JSAC >for). I'm sure you had a good reason for this subject's being pub- >lished in JSAC, but that reason is not immediately obvious to me. That particular JSAC happened to be a special issue on Personal Computer Communication. We had come at the problem of parallelism from a communications perspective. Having designed the BBL system to run on a network of idle PC's, the special issue struck us very appropriate.
ozalp@dm.unibo.it (Ozalp Babaoglu) (12/19/90)
In article <12179@hubcap.clemson.edu> anand@top.cis.syr.edu (Rangachari Anand) writes: >Using a group of workstations connected on a LAN as a prallel >computer is an idea that is continually being rediscovered. Given the >high speeds of the available workstations, this is clearly an Idea Whose >Time Has Come. add one more to the list: Paralex, being developed here at the university of Bologna, Italy. i am enclosing a brief description of the scope and goals of paralex. for further information, please contact me by e-mail. -- Paralex: An Environment for Parallel Programming in Distributed Systems One of the many advantages of distributed systems is their ability to execute several computations on behalf of a single application in parallel, thus improving performance. In fact, at a certain level of abstraction, there is little difference between a distributed system and a losely-coupled multiprocessor computer. We cannot, however, treat distributed systems as if they were uniform multiprocessor parallel machines due to the following characteristics: o High latency, low bandwidth communication o Presence of heterogeneous processor architectures o Communication link and processor failures o Multiple independent administrative domains. Thus, if we can address these issues, a distributed computing resource such as a collection of workstations could be viewed and used as if it were a poor man's ``super computer.'' To make a distributed system suitable for long-running parallel computations, support must be provided for fault tolerance. Many hours of computation can be wasted not only if there are hardware failures, but also if one of the processors is turned off, rebooted or disconnected from the network. Given that the components of the system (workstations) may be under the control of several independent administrative domains (typically a single individual who ``owns'' the workstation), these events are much more plausible and frequent than real hardware failures. It is our thesis that reasonable technologies already exist to address the problems related to distribution, communication and fault tolerance of applications in distributed systems. What remains a challenge is the task of {\em programming} reliable applications that can benefit from the parallelism and fault tolerance that distributed systems have to offer. The Paralex Project has been undertaken to explore the extent to which the programmer can be liberated from the complexities of distributed systems. Our goal is to realize an environment that will encompass all phases of the programming activity and provide automatic support for distribution, fault tolerance and heterogeneity in distributed and parallel applications. Paralex makes extensive use of graphics for expressing computations, monitoring, controlling execution and debugging. In fact, the programming paradigm supported by Paralex is best suited for parallel computations that can be viewed as collages of ordinary sequential programs. The interdependencies and data flow relations between computations in a parallel program are expressed in a natural way using a graphical notation. In the limit, interesting new parallel programs can be ``programmed'' by reusing existing sequential software and without having to write a single line of traditional code. A prototype of Paralex is being built at the Department of Mathematics, University of Bologna, Italy for a network of Sun-3, Sun-4 and Vax architecture workstations running Unix. The graphical interface is based on X-Windows and the Open Look Intrinsics. Automatic support for fault tolerance is achieved through the ISIS toolkit. -- Ozalp Babaoglu E-mail: ozalp@dm.unibo.it University of Bologna, Dept. of Mathematics Piazza di Porta S. Donato, 5 TEL: +39 51 354430 40127 Bologna (ITALY) FAX: +39 51 354490