[distcc] avoiding work
Harold L Hunt II
huntharo at msu.edu
Fri Jan 30 00:32:50 GMT 2004
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
More information about the distcc
mailing list