Re: Time for a compile server status update?

[Per Bothner <per at bothner dot com>]

Dan Kegel wrote:

> it's been a whole six weeks since we last heard news
> about the compile server 
> (http://gcc.gnu.org/ml/gcc/2003-10/msg01398.html et seq.)
> Could you post a short note with where things are now?

Yes, it is time for an update.  Partly because Monday is my last day at 
Apple (due to policies about maximum length of contracting), so I will 
no longer (for now) be able to spend much time on the compile server. 
However, Mike Stump will still be working on in for most of his time, 
and others, including Steve Naroff will be helping out.

First, correctness/safety:  The compile server handles real C programs 
and real header files (which can be pretty ugly) quite will.  We've 
compile d125 .c files (a large subset of those that make up cc1) with 
their associated #included files with a single invocation of cc1 in 
server mode, on both GNU/Linux (Fedora 1.0) and Mac OSX Panther.  The 
compile suceeds and produces .o files that can linked together to 
produce a working cc1.  There are some regressions in the testsuite 
(which is run in non-server mode), and there are known ways you can 
trick the compile server to "do the wrong thing", so we're not quite 
there yet, but this is very encouraging.

This is for C, which is what I have been working on.  Mike Stump has 
been working on C++, which is more complicated.  He has also a 
potentially faster design for "conditional symbol tables", which speeds 
up header file re-use.  Mike can update on these.

Next, speed:  This dependx very much on the "work mix".  A simple .c 
file that does nothing except #include <Carbon/Carbon.h> (which includes 
most of the headers for Apple's older Carbon GUI framework) achieves 
close to 100% reuse (i.e. header file fragments whose declarations can 
be reused without requiring reparsing).  The exception is a few system 
header files like stdarg.h and limits.h.  The actual speed-up is about 
10x for second and subsequent compiles using the server, compared to 
using the same cc1 executable in non-server mode.  Mike has some 
preliminary numbers suggesting we can do even better.

But of course this is for the best case, where compilation times are 
dominated by header files that are included many times in different 
compilation units.  Such applications are the ones where we expect the 
most benefit from the compile server -  just as for pre-compiled headers.

We also get a definite speedup compiling 14 .c files using the server. 
These are the first 14 files mentioned in the TEST_TARGET rule in the 
gcc/makefile, and are mostly part of cpplib, so these files are medium 
size with modest header file reuse.  The speedup is around 20% if you 
look at "user" time as reported by 'time' (adding server and client time).

If I run 121 .c files (all of TEST_TARGET in gcc/Makefile) the result is 
not so good.  We don't expect much of a benefit, because many of the .c 
files are huge, and there aren't that many header files to re-use.  So 
on my Powerbook it comes out even.  However, on my GNU/Linux server 
using the server appears to be about 40% slower in this case.  (However, 
in absolute numbers the latter is faster.)  My best guess is that we're 
getting hit by the poor locality (page and especially cache) of Gcc's 
data structures.  This is an issue when not using the compile server, 
but it becomes worse with the compile server just become we now have so 
much more stuff saved in memory.  So any efforts to improve Gcc cache 
locality will probably benefit the compile server even more.

The gcc/Makefile has a couple of rules for trying out the compile 
server:  Do 'make start-server' to start the server.  (This works on 
GNU/Linux, but may require some tweaking on other platforms since it 
starts up cc1 directly without going via the gcc command.)  To compile 
the files listed in TEST_TARGET, do (in a different window) 'make 
recompile-with-server'.

> Also, it would be cool if you could say a few words about
> what it would take to someday run the compile server in parallel
> on multiple computers, distcc style.  The obvious "just use
> distcc" probably won't help as much as one would think
> because distcc runs the preprocessor before shipping the
> code out, whereas (judging by
> http://per.bothner.com/papers/GccSummit03-slides/) your
> compile server really wants the original source files.
> Presumably distcc could send over source files if
> the distcc server hadn't seen them before (based on a
> hash of the file).   In large installations, you'd want
> to go just on a hash of the file's contents, not on its
> absolute path, since multiple users might be compiling
> the same file.

I think you've said it.  A shared/distributed file system also makes 
sense.  Our initial "target" is a developer with a laptop or desktop 
machine and a single or small number of CPUs.
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/