Re: compile server design document

[Per Bothner <per at bothner dot com>]

Alexandre Oliva wrote:
> I'm yet to give your text and patch a closer look, but at a first
> overview, it doesn't seem to be very friendly to preprocessed files,
> which GCC has been more and more commonly fed by people who use ccache
> and distcc.

Gcc is currently optimized for *not* creating preprocessed files.
So systems like distcc that use preprocessed files are deliberately
giving up some performance (and the "mainstream" of work in gcc
compilation-speed) improvements - in the hope of gains in other
ways.  In addition ccache has to calculate a hash of each input
file.  My hope is that that the compile server can eliminate the
need for ccache.

Distributed compilation is still useful, but I'm not that comfortable
with distcc's approach of shipping preprocessed files.  It substantially
increases network bandwidth.  Of course this isn't really a problem
if you're on a fast network - but in that case why not instead get the
header files using (say) NFS or FTP - and have them be cached by the
compile server?

My preferred approach would be just running one or more compile
servers per node.

> Is there any effort in the direction of improving compile
> performance in the ccache+distcc scenario, by say recognizing
> fragments (as you call them) from header files even when they're
> encountered in a previously-preprocessed file?

It's not something I've considered, nor it's not a priority for
me at this point.  The problem is that you have to quickly
recognize that a header file fragment in a preprocessed file
is the same as an already-seen fragment.  Presumably you can
do this using hashing.
--
	--Per Bothner
per at bothner dot com   http://www.bothner.com/per/