Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!cwjcc!gatech!hubcap!encore!pinocchio!aral
From: encore!pinocchio!aral@EDDIE.MIT.EDU (Ziya Aral)
Newsgroups: comp.parallel
Subject: Re: distributed make(1)?
Summary: More variations on the theme...
Message-ID: <5515@hubcap.clemson.edu>
Date: 18 May 89 12:05:55 GMT
Sender: fpst@hubcap.clemson.edu
Lines: 35
Approved: parallel@hubcap.clemson.edu

In article <5509@hubcap.clemson.edu> brooks@vette.llnl.gov (Eugene Brooks) writes:
>Just for the record, Sequent introduced the idea of parallel make in their
>product and deserves due credit.  The idea caught on with the other makers
>of general purpose parallel computers very quickly.

Just for the record, I think Bell Labs gets some credit too. At least that's
where we "stole" the idea :-)

Around here, we have one more variation on this same theme. Our diskless
Suns use Mulitmaxen as NFS servers. We have a small program that uses
Sun RPC to invoke parallel make using a version of GCC that generates code 
for a Sun. When it comes time for the link, we RPC back to the Sun loader.
You type "make" on the Sun and BOOM, you get a dozen compiles at once.
Each stream is somewhat faster too. Voila, "new life for old Suns", etc.,
etc....

It beats distributed make hands down because:

    a) Network traffic is reduced (the compile is local to the server)....

    b) NS32532's tend to be faster than 68020's...

    c) We don't poke around the network trying to glom cpu's....

The same trick works for parallel grep. In fact, the same trick even 
works for a lot of single-stream stuff, assuming the above...

Hey, wait a second! What if instead of a bunch of workstations on a network,
we had these big computers that we connected to with dumb terminals and
did all the work locally, and....

All kidding aside, a multi hooked up to a bunch of workstations produces
an interesting hybrid.

				    Ziya Aral