Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!husc6!bu-cs!buengc!bph
From: bph@buengc.BU.EDU (Blair P. Houghton)
Newsgroups: comp.unix.questions
Subject: Re: Getting the most for a process.
Message-ID: <4532@buengc.BU.EDU>
Date: 14 Oct 89 01:42:50 GMT
References: <593@cogent.UUCP> <12034@cgl.ucsf.EDU> <40090@bu-cs.BU.EDU> <1029@crdos1.crd.ge.COM> <20140@mimsy.UUCP>
Reply-To: bph@buengc.bu.edu (Blair P. Houghton)
Followup-To: comp.unix.questions
Organization: Boston Univ. Col. of Eng.
Lines: 43

In article <20140@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>In article <1029@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.COM
>(Wm E Davidsen Jr) writes:
>>  The Encore version of make looks at an environment variable and
>>determines how many copies of the ccompilers to start. On a machine with
>>8 cpu's you get a blindingly fast make compared to doing the same thing
>>(in serial) on a faster machine.

But not perfectly reliably.  It's messed up on some dependencies in
large makes we've run in the past.  Sometimes it gets ahead of itself
and goes on to the next step before some of the parallel cc'ing is
completed in this step...it hasn't done this in a long while, though.
It doesn't stop me from setenv'ing PARALLEL to 12, or anything...it's
just _one_ more possible reason for having to rerun a "make World." :-)

>Unfortunately, the Encore version of cc, which is apparently a Greenhills
>C compiler, has all of its `phases' built in.  Thus, if you are compiling
>a single file, you cannot preprocess on cpu 0, compile on cpu 1, and
>assemble on cpu 2 all at the same time.

Much harder to manage if you've got eight processors and PARALLEL==3.
Might even cause a performance decrease if the ccom phase gets assigned
to the overlapping processor.  With the entire cc constrained to one
processor, you're assured of eight simultaneous compilations (for whatever
an assurance of regularity from a computer is worth; I mean, aren't they
supposed to manage the complexities and leave us to the iced tea?).

>Given the standard edit/compile/debug cycle, this---combining
>everything---seems to me to be a major mistake.
>Well, not so major as all that, perhaps, since most of the time is
>spent in the compilation part, not in preprocessing or assembly.
>Still, the potential was there, and would return if Encore used gcc as
>their standard compiler.

Uh, who does?  :-)  Seems to me you can usually snarf a _newer_ version
of gcc than any computer company is prepared to deliver with a packaged
system.  Then again, I haven't tried to build gcc on our Encore (it kicks
silicon butt on the uVAXen, tho').  Any reason I should or shouldn't?

				--Blair
				  "I just want to know when rn
				   is going to take advantage of
				   parallelism.  :-) :-) :-)"