[distcc] avoiding work

[Benjamin S. Scarlet]

On Thu, 2004-01-29 at 19:18, Martin Pool wrote:
> On 29 Jan 2004, "Benjamin S. Scarlet" <bsfdccl0 at greynode.net> wrote:
> > It seems to me that it _might_ be possible to get more for less by
> > hooking distcc into gcc differently, at the expense of not distributing
> > the assembly.
> > 

> Where is the much less work?

Did I say "much"? :-) You're quite right -- it may well not be worth it,
but I thought it would be interesting to consider.

> > *) gcc supports several facilities for such a substitution (either the
> > GCC_EXEC_PREFIX or COMPILER_PATH environment variables, or the -B flag).
> 
> This might be more intrusive to install than the current masquerade
> setup.

Possibly.

For gcc to find distcc would be easy -- installing distcc would make a
directory somewhere containing nothing but two links to its binary,
named cc1 and cc1plus, and then that directory would go on the front of
COMPILER_PATH. For distcc to find the correct real cc1, however, might
be a problem, both locally and remotely.

> > *) If distcc were invoked by gcc in place of cc1, the other passes
> > wouldn't be distcc's problem -- it would get precisely the input it
> > wants without having to think so much.
> 
> No, it would still have to work out whether the compiler could be
> remote.  For example, invocations which write out profile data cannot
> be remote.  The amount of argument processing would be smaller though.

Yes, that's my point, such as it is. 

> I don't think the process overheads are sufficiently expensive to
> matter.  fork is cheap[0].

OK. (If there were any cost, I'd have expected it to be in the exec and
subsequent dynamic loading of shared libraries, not the fork, but I'll
still accept that the total make much difference compared to the time to
run the real compile).

> I don't think the gcc wrapper is very expensive either.  Or have you
> measured it?

Nah. I agree that wouldn't make much difference.

> I agree that this would be another possible way to write it.  You
> lose a bit (or maybe a lot) of ease of installation, but the argument
> scanner can be simpler.  You might also lose the possibility of using
> compilers other than gcc, but I'm not sure that anyone has ever
> succeeded in doing that so it might be moot.
> 
> I don't see any reason to rewrite it now though.  Do you think there
> is one?

Not enough of a reason, no.  It's quite likely that, having just run
into two (minor) bugs with the current argument processing, my
perception of the relative value of a better way to process arguments is
exaggerated.  It does seem awkward that distcc must duplicate the work
in the gcc driver of interpreting gcc's vast collection of arguments.
Without a clean way for distcc to find the backends, though, this
approach to avoiding that duplication doesn't pay off enough.

> > It seems to me that if assembly is quick enough to do locally, such a
> > rearrangement might be a win.
> 
> Assembly can be relatively cheap.  On the other hand, the assembler
> input can be larger than the object code, and in some cases this might
> be decisive.

This comment, and another you made later about newer gcc's integrating
cpp and cc1, are indeed even bigger problems with the idea.

>From this point, though, it seems like one way to look at the situation
would be that gcc has a lot of information and code which would be
useful for what distcc does. It has the definitive argument processing
code, it knows under what name it was invoked, it knows where its cc1
is, etc.