[distcc] PCH Headers and distcc (again!)
saschad at crytek.de
Wed May 28 13:12:02 GMT 2008
Jamie Kirkpatrick wrote:
> Hi Sascha
> Good to hear this was as important to someone else as it was to me. I
> found that once PCH's were working things compiled a hell of a lot
> quicker: I was getting gains in the region of what is touted on the
> website using two machines of similar power. I do think this is an
> important addition therefore.
That probably depends on your setup, and maybe the setup here is not
really representative. So if you found that PCHs really speed things up,
then let's do it :)
(For our "inline-intensive" C++ code, the bottleneck without PCHs is the
preprocessor speed on the client machine. Due to different
architectures, a PCH build must be done 100% on the server, so if the
clients are powerful enough to keep their compile slots busy, then
there's no speedup using PCHs at all - the reduced compile times on the
build server are eaten up by the time required to transfer the PCHs. In
our local setup, for an 8-core client PCHs are irrelevant, for a
quad-core client the speedup is about 15%.)
> Having read about your solution (which I commend you on) I wonder
> whether or not we shouldnt retry patching the PCH's to alllow the
> checksum test to be passed on the target compiler. I've read the code
> and it seems to me we should be able to reverse engineer that code,
> but I'm not sure how we can find out what the correct checksum for
> each version of GCC would be.
I don't think this is the way to go. The GCC team certainly did not add
the checksum for fun, and I am pretty sure that simply bypassing that
test just leads to a crash in most cases. It does not work for x86/Linux
vs. x86/Win32 (I tried it), even though that's the same processor, just
a different OS.
> I do think if this could be made to work it would be a lot cleaner,
> though users would have to understand that they take a risk if they
> mix versions of GCC. They do this anyway at the moment though so I
> don't see a major difference.
Yes, but mixing ELF files from different compilers is not that bad - the
ELF binary format is well defined and portable across host platforms.
(You may still run into problems mixing different versions of libstdc++,
but that's a different issue.)
> RIght now though would it not be worth incorporating your changes but
> made to work for the same version of GCC on each side? That would at
> least be a start, and we could look at adding the patching later?
> Does this need a fork of the main codeline to get things running? If
> so, could we think about using Git and some free hosting like GitHub
> to allow efforts to be shared? If the core maintainers are happy to
> have this work takeplace in the main repository then fine, but if not
> (based on the idications you gave) this could be a way forward.
Let's do it - I just got permission from our management to release the
I'm fine with using GIT for collaboration. DistCC uses Arch, so it's
probably best to clone the main repo via git-archimport. Do you know if
GitHub (or some other free GIT hosting site) supports that? If not, then
I could clone the DistCC repo to my private box (accessible via DynDNS)
and then clone that to a GitHub repo.
More information about the distcc