[distcc] Re: separating compiler and assembler: benchmarks

[Stuart D. Gathman]

Martin Pool wrote:

>>With -pipe, sending preprocessed source to the volunteer 
>>and receiving assembler output occur nearly simultaneously.  
>>
>Is it really true that it's simultaneous, or does it only appear so
>because the remote machine is faster?  My impression was that gcc had
>to read and digest the whole source before it could start producing
>output, but perhaps not.
>
Gcc writes assembler output after each toplevel item.  Assembler output 
is produces after each static of global variable (initialized or not), 
after each implemented class for C++ (writes vtbl and auto methods), and 
after each function definition.  Unless your C source consists of one 
gigantic function, there is plenty of pipelining of input / output.

Your iompression might hold true for other compilers - especially those 
that try to do more global optimization.

>In any case, realistic .i files will be mostly headers, which won't
>produce any assembly.  So even at best there won't be any output until
>it gets down to the tail of the input file.
>
Which is why I tested it.  There is still plenty of "meat" in non 
trivial C source.   There is a 2x speedup to be gained (without using 
-j2), and that is with the local assembler on a machine that is 10x slower.

>>However, when the compiler runs on a volunteer, and the assembler
>>runs locally, -pipe provides a factor of 2 speedup.
>>
>
>... if you ignore parallelism, which is the main point of distcc!
>Yes, you're stripping out time waiting for network transfers, and
>that's a good thing, but it's not so important if there are other
>tasks that can run while the transfer is in progress.
>
Call me picky, but I expect distcc to perform at its best even without 
parallel make.  Some makefiles are broken and do not work with -j2.  It 
is complicated and slow to debug them.

BTW, I discovered a drawback to using -B to hook the compiler passes. 
 On AIX, gcc adds the directory it find cc1 in to LIBPATH for the 
executable when used on a link step.  Annoying, but not fatal.  The 
distcc -B directory will be secure (i.e. writable only by root) when 
installed.  Presumably, distcc will be smart enough not to pass -B when 
there is no source input, which will eliminate the extra LIBPATH entry 
in most cases (where linking is a separate invocation).