Book XML design specs, extending LFS

Gordon Schumacher gordon at rebit.com
Sat Nov 22 12:47:41 PST 2008


Gilles Espinasse <g.esp at free.fr> wrote:

> I doubt distcc is a big gain on x86_64.
> CPU is so fast comparing to the network and with lot of internal cache that
> minimize the gain you could achieve using other machines.
> That's supported on IPCop and the gain reported was only 5% adding another
> machine with same power. So that's not worst the work and probably almost
> nobody really use it.
> Should be more usefull if you have a cloud of slow alpha, pcc or sparc
> machines.
> To be more efficient with less network traffic needed, you would need a
> system able to distribute an entire package compilation (when packages are
> fully independant) at each machine. I am not so sure distcc will help on
> that scheme.
>   

I realize that I am probably not the typical case, but I saw a
substantial gain - I had four machines (10 cores total) hooked up via
GigE, so network latency was not so much an issue for me.  But you have
a good point in that being able to distribute the packages themselves
would be even better; I'll contemplate good ways to do that; at the very
least, in order to support the "parallel package build" idea, one would
need a tag for a step specifying which steps it is dependent on.

> In contrary, ccache is approximately an overall 25% gain after the first
> build.
> That really help compiling the kernel for example (gain should be 50%
> there).
>   

So in light of that, I'll rephrase that to "support for compiler
wrappers" in general.



More information about the lfs-dev mailing list