[distcc] Re: separating compiler and assembler: benchmarks

[Martin Pool]

On  3 Mar 2003, "Stuart D. Gathman" <stuart at bmsi.com> wrote:

> I have benchmarked my version of remote compile with and without -pipe.  I 
> can say that the -pipe option is extremely important.  When properly 
> implemented, it cuts the time spent waiting for files to copy over the 
> network in half.

> 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.

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.

> Without -pipe, the copy in each direction must happen sequentially.
> Using -pipe does not help distcc currently, because the assembler
> does not (and cannot given the kinds of forward reference problems
> it must solve) incrementally write the object output.

> 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.

-- 
Martin