Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!udel!gatech!hubcap!kyw
From: kyw@cs.purdue.edu (Ko-Yang Wang)
Newsgroups: comp.parallel
Subject: Re: Looking for a message passing package to run on the Sun
Message-ID: <6490@hubcap.clemson.edu>
Date: 18 Sep 89 16:08:48 GMT
Sender: fpst@hubcap.clemson.edu
Lines: 77
Approved: parallel@hubcap.clemson.edu

In article <6489@hubcap.clemson.edu> avsd!childers@decwrl.dec.com (Richard Childers) writes:
>baden@lbl-csam.arpa (Scott Baden [CSR/Math]) writes:
>
>>I'd like to tie together our local bevvy of suns into a multicomputer
>>for solving scientific problems. I need simple facilties to
>>fork off processes and to handle message passing.
>>Are there any software packages out there in netland to do this?
You may want to look at ISIS from Cornell.
ISIS provides some useful functions that allow you to implement distributed
and fault-tolerant systems relatively easy.
It contains utlities for lightweight tasks, message passing, broadcast,
synchronizations, etc.
They have a beta version (V1.3.1) for an array of different architectures
including Suns(SunOS), Vaxs(4.3Bsd), Gould, HP Spectirum 300(HPUX), PC/RT(AIX),
MACH, Next, APOLLO.
Better yet, this package is free and is actively supported by the ISIS group.
Contact:
	ISIS Project (Attn: M. Schimizzi)
	Department of Computer Science
	Upson Hall
	Cornell University
	Ithaca, New York 14853}
	Phone: 607-255-9198
	E-mail: schiz@cs.cornell.edu
	Contact person: Margaret Schimizzi

>I recall reading about a remote execution daemon that had been developed
>experimentally a few years ago ... at UC Berkeley.
>
>I recall reading about it in the USENIX journal, oh, about three years ago.
>
>I'll bet a few hours skimming through old USENIX journals might benefit
>you. As I recall, the daemon, when given a job, polled the network to see
>what machines weren't busy and passed the job out to appropriate servers,
>also running this daemon. When they were done, it was returned.
It is not very difficult to implement (call back) rpc to do this.

>
>I think it didn't fly because the overhead was too high, networking and on
>the machines that ran the daemon, to make it cost-effective in the environment
>it was conceived in. But it would still seem like the ideal core for a loose
This depends on your application.
I designed a project for a graduate course of computer networks in which
the students split a very long inner-product into a set of independent
vector operations and run them on a set of Suns. If the vector is long enough
the overhead is tolerable. This applies to matrix multiply and the gangs also.
However, for more general problems, the data dependences make spliting the
program into tasks very difficult.
>approach to multiprocessing, provided you had a front end that was capable
>of dividing the task up into independent pieces that could be processed w/o
>dependencies ....
Well, this front end is much, much more difficult to build than the
distributed daemons. In general, the technology for
generating code (such as compilers) for distributed machines is still at
its infancy.
The last requirement (w/o dependences) is too strong for most applications.
You should be willing to handle few dependences with message passing.
I don't think there is any tools out there that can handle this yet.
>
>>	Scott B. Baden
>>
>>	Lawrence Berkeley Laboratory
>>	Berkeley, California
>>	baden@csam.lbl.gov
>>	...!ucbvax!csam.lbl.gov!baden
>
>-- richard
>
> *      ..{amdahl|decwrl|octopus|pyramid|ucbvax}!avsd.UUCP!childers@tycho     *

Ko-Yang
-------------------------------------------------------------------------------
Ko-Yang Wang                    | kyw@cs.purdue.edu    |  -----  ------ ___`___
Department of Computer Sciences | Parallel/Distributed |  __|__   [] |    ---
Purdue University               | Processing, CAPO     |    |        |    ---
West Lafayette, IN 47907        | (317) 494-0813       |`-------,   \|   [===]
-------------------------------------------------------------------------------