This is the mail archive of the
mailing list for the GCC project.
Re: gcc 3.5 integration branch proposal
- From: Mike Stump <mrs at apple dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: Geoff Keating <geoffk at apple dot com>, Eric Botcazou <ebotcazou at libertysurf dot fr>, Scott Robert Ladd <coyote at coyotegulch dot com>, Robert Dewar <dewar at gnat dot com>, gcc at gcc dot gnu dot org, Nick Burrett <nick at dsvr dot net>, Gabriel Dos Reis <gdr at integrable-solutions dot net>, Marc Espie <espie at quatramaran dot ens dot fr>
- Date: Tue, 20 Jan 2004 12:40:47 -0800
- Subject: Re: gcc 3.5 integration branch proposal
On Tuesday, January 20, 2004, at 11:03 AM, Alexandre Oliva wrote:
Is the compiler server multi-threaded?
Even if it were, Mosix wouldn't get anything from it since threads
that run on a shared memory space don't migrate to different hosts.
At least last I
looked, they didn't.
Right. And since we don't (currently) share memory spaces, there isn't
Sure, if you start multiple compile servers, they can migrate to
different boxes. Ditto for distcc builds. But then each one
duplicates some of the compilation that the compiler server is
supposed to save, so by distributing the load you diminish the
benefits of the sharing.
Yes, this is true. The problem is, if the CPUs are idle, then in the
amount they wait, waiting for one CPU to compute an answer, they could
have computed it themselves and started compilation. In addition to
computing the answer, it would have to be shipped over the network as
well, which just requires more resources. But, yes, long term, it does
make for an interesting research project. What level of granularity is
appropriate... and how to manage it.
We do distcc and PCH today, perfectly compatible as well.
How can you do PCH with distcc, if distcc just ships the preprocessed
sources to the remote box?
:-) You'd be interested in our magic -fpch-preprocess option. It lets
you ship a file that is 100x smaller, and requires 6x less processing.
Check out http://gcc.gnu.org/ml/gcc/2003-03/msg00369.html and
eventually I'll submit it again... Maybe in the coming year it might
get in, here's to hoping. We've been shipping it for a while now.
Usage of distcc simply disables PCH for
me. Are you hiding any patches from the rest of us, that embed PCH
data in the preprocessor output?
This might be nice, but it would probably be yet another incompatible
change in the preprocessor output format that might cause problems to
No, it is fairly safe and not the default. It does require that distcc
know to put on one extra option, but I thought that was best, too many
users of -E otherwise.