brian@caen.engin.umich.edu (Brian Holtz) (05/16/89)
Can anyone give me a pointer to literature on, or even an ftp target for, a distributed version of make? GNU make spawns parallel jobs locally, and has stubs for distributing them; I've read that Concurrent Make from Bell Labs/ Murray Hill actually handles distribution, also. Has any other work been done on this?
eugene@eos.arc.nasa.gov (Eugene Miya) (05/16/89)
There are several concurrent make(1) programs around. There is one
on our Sequent and I think Encore has one on the Mulitmax, but I've not
used it. The function (compilation) is typically a very simple coarse
function, so it is easily amenable.
What I would hope to see is that these programs be made widely available
to the Unix community. Rather than keep them as company value-add-ons,
that such a simple (what company is going to gain leverage because of a
simple program?), that these types of tools be made freely (or small fee)
available. My concern is mostly that the semantics of tools like
a parallel or distributed make be consistent across manufacturers
(especially as we move into increasing heterogeneous environments).
If your machine does not use make (ala it runs a non-Unix type OS),
that is your loss. "Roll you own."
Longish signature follows "Type 'n' now"
Another gross generalization from
--eugene miya, NASA Ames Research Center, eugene@aurora.arc.nasa.gov
resident cynic at the Rock of Ages Home for Retired Hackers:
"You trust the `reply' command with all those different mailers out there?"
"If my mail does not reach you, please accept my apology."
{ncar,decwrl,hplabs,uunet}!ames!eugene
Live free or die.jw@sics.se (Johan Widen) (05/16/89)
>Can anyone give me a pointer to literature on, or even an ftp >target for, a distributed version of make? GNU make spawns Adam de Boor wrote a program called pmake (for parallel make), while he was at Berkeley. It will distribute jobs between a set of machines "of the same architecture". Pmake actually relies on a set of separate programs to do the load balancing. These programs can be used by any software, not just pmake. I found a version of this program on a tape and has since fixed a number of bugs (most are related to pmake being developed under Sprite, while we run SunOS 4). We have it installed on Sun-3's and Sun-4's under SunOS 4, including the loadbalancing. We also have it running on a Symmetry, with local parallelism (a la GNU make) only. Pmake uses up a couple of file descriptors for each child it forks off locally. As the Symmetry OS (DYNIX) allows only 20 open files per process (sigh), this puts a fairly severe limit on the parallelism. The loadbalancing scheme has some interesting features. Each machine is assigned to a class. Work is only shared between machines belonging to the same class. 'Import of work' can be further restricted by explicitly specifying which machines may export work to our machine. A machine may decide if it is willing to import work depending on 0 or more of: how long the machine has been idle (since someone touched the keyboard), the load average, the amount of free swap space. A nit in our current version of pmake is that the output from the children to the screen seems to be block buffered rather than line buffered. I have found that pmake gives a substantial speedup, especially if the machines have a reasonable amount of memory (ie more than 4 MBytes). Still, I tend not to use it very often. The reason is that many Makefiles have been written with no thought given to parallelism, they often rely on quirks in the standard make. Another problem is the NFS file caching: it takes time for a machine to discover that another machine has modified a file. These problems are usually easily dealt with when you write new Makefiles, but they can be a real pain when you are confronted with an already existing source tree. A version of pmake (archive/pmake.fix2.Z) can be retrieved from sics.se (192.16.123.90) -- Johan Widen SICS, PO Box 1263, S-164 28 KISTA, SWEDEN Internet: jw@sics.se Tel: +46 8 752 15 32 Ttx: 812 61 54 SICS S Fax: +46 8 751 72 30
cline@sun.soe.clarkson.edu (Marshall Cline) (05/17/89)
In article <5486@hubcap.clemson.edu> brian@caen.engin.umich.edu (Brian Holtz) writes: >Can anyone give me a pointer to literature on, or even an ftp >target for, a distributed version of make? GNU make spawns Others have mentioned the make(1) under DYNIX (Sequent Balance, etc). An interesting aside, however, is that spawning make(1)'s tasks in parallel isn't always possible (ie: isn't always _correct_). Ex: Suppose "A" depends on "B", and "B" depends on "C". The make script might say: build "B" from "C" build "A" from "B" The simplistic solution would be to hard-wire a "&" after each command in the Makefile. This will cause each to run asynchronously, which will be disasterous ("A" might get built from the old "B", or from the new "B", or worse yet, from a mixture). The DYNIX make(1), as well as _any_ distributed Make which is correct, will force the above two commands to run _sequentially_, perhaps on the same PE... Other non-dependent operations can naturally be run in parallel, on the same (asynchronously), or on different (simultaneously) PEs... The point is that, given that N files have to be "made", you may still have to run each sequentially. On the other hand, you may be able to run all N at once; it all "depends" on the "dependency" tree... Just an aside... Marshall ________________________________________________________________ Dr. Marshall P. Cline ARPA: cline@sun.soe.clarkson.edu ECE Department UseNet: uunet!sun.soe.clarkson.edu!cline Clarkson University BitNet: BH0W@CLUTX Potsdam, NY 13676 AT&T: (315) 268-6591
brooks@vette.llnl.gov (Eugene Brooks) (05/17/89)
In article <5491@hubcap.clemson.edu> eugene@eos.arc.nasa.gov (Eugene Miya) writes: >There are several concurrent make(1) programs around. There is one >on our Sequent and I think Encore has one on the Mulitmax, but I've not >What I would hope to see is that these programs be made widely available >to the Unix community. Rather than keep them as company value-add-ons, Just pick up a copy of GNUMAKE, which in the last few versions has parallel make features added. GNUMAKE has the advantage that you don't have to sprinkle in '&' tokens, it just reads the standard makefile and goes. It of course has the best advantage of being FREE, and remaining that way! I have a patch to cause GNUMAKE to read the PARALLEL environment variable as the Sequent parallel make does, but I wouldn't dream of putting in the '&' support. The patch is a trivial hack. 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. brooks@maddog.llnl.gov, brooks@maddog.uucp
eugene@eos.arc.nasa.gov (Eugene Miya) (05/18/89)
Response to Jim's mail-- I think there has to be made the distinction of a parallel make versus a more loosely coupled distributed make. I think the credit, if that is really important, goes to the folks at Bell Labs like Rob Pike, Mash, Ken and Dennis for a thin wire make. >>What I would hope to see is that these programs be made widely available >>to the Unix community. Rather than keep them as company value-add-ons,... > >Agreed. But there is no good way for someone like CRI to effectively >sell it cheaply >and they have little incentive to give it away. >Perhaps CRI could be convinced the "prestige" or some such is >worth the giving away of such software. But even this won't work I think GNU is an excellent example. It is in CRI, Sequent's, Encore's and everyone elses best interests because these machines are rarely use in homogeneous environments. IF I have tools which run one way on my workstation and a different way on my 2, life would have more griff. Why I'd spend even more time in the Cray window than the news window ;). Some simple tools should just be given away. It only hurts the competition more which don't have it. BTW, I don't think the Bell version ever got out of the Labs. >>If your machine does not use make (ala it runs a non-Unix type OS), >>that is your loss. "Roll you own." > >VMS has a "make" clone called MMS. But VMS is becoming more and >more Unix-like every day... BTW: make is just okay. There are better systems, make is just a least common denominator. Make has lots of problems, but Cedar/Mesa doesn't run on everything (and it has problems, too.). You can also learn about a company's Unix port by how well make supports a language like Fortran. If you have simple file.f, and they tout their new souped up Fortran compiler and you make a quick Makefile (actually I do this for a dozen programs at a time): file: It's interesting to watch which fortran compiler if any is grabbed by the dependency. So far only our Crays generate the correct compiler dependences. These people must program their machines! The 2 and Y produce a cf77. Our ETA-10, our Amdahl, other machines, require modifying the macro. ftn77, 77, and things we won't mention. Respecting confidentially. --eugene
aral@EDDIE.MIT.EDU (Ziya Aral) (05/18/89)
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
prc@erbe.se (Robert Claeson) (05/18/89)
In article <5509@hubcap.clemson.edu> brooks@vette.llnl.gov (Eugene Brooks) writes: >In article <5491@hubcap.clemson.edu> eugene@eos.arc.nasa.gov (Eugene Miya) writes: >>There are several concurrent make(1) programs around. There is one >>on our Sequent and I think Encore has one on the Mulitmax, but I've not >Just pick up a copy of GNUMAKE, which in the last few versions has parallel >make features added. GNUMAKE has the advantage that you don't have to >sprinkle in '&' tokens, it just reads the standard makefile and goes. Just like the pmake on the Encore Multimax machines. It just reads the standard makefile and goes. -- Robert Claeson E-mail: rclaeson@erbe.se ERBE DATA AB