[distcc] avoiding work

[Harold L Hunt II]

Martin Pool wrote:

> On 29 Jan 2004, "Benjamin S. Scarlet" <bsfdccl0 at greynode.net> wrote:

[snip]

>>*) In this way, much less argument processing would be necessary (I
>>think there're only one or two flags at the cc1 level which should
>>prohibit distribution -- most of the weird output cases happen at a
>>higher level). More compilations would be distributed, like
>>gcc -xc++ foo.c -o foo.o
>>or
>>gcc foo.c -o foo
>>*) As a possible side benefit, the number of process invocations per
>>file would also decrease: Now, it looks like
>>[distcc [gcc [cpp]] -remote-> [gcc [cc1] [gas] ] -local-> ... ]
>>after such a change it would look like
>>[gcc [cpp] [distcc -remote-> [cc1]] [gas]]
> 
> 
> I don't think the process overheads are sufficiently expensive to
> matter.  fork is cheap[0].

Not that Cygwin is the primary platform, or even close to it, but fork 
costs a fortune on Cygwin.  configure scripts that run in 10 seconds on 
an old Linux box take 15 minutes or more to run under Cygwin, primarily 
due to the slowness of emulating fork correctly.

Another poster had mentioned how the CPU is pegged at 100% just 
pre-processing files on Cygwin, let alone actually compiling anything. 
As it is, you have to have a Cygwin build host that is something like 4 
times faster than your remote hosts in order to actually be able to 
distribute some work; currently I see only blips of activity on my 
remote host when my build host manages to get an extra file 
pre-processed in time to be sent across the wire.

Just something to keep in mind.

Harold