On 29 Jan 2004, "Benjamin S. Scarlet" <[EMAIL PROTECTED]> 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
__ distcc mailing list http://distcc.samba.org/
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/distcc
