From: Mike Stump <mrs@apple.com>
To: Alexandre Oliva <aoliva@redhat.com>
Cc: Geoff Keating <geoffk@apple.com>,
Eric Botcazou <ebotcazou@libertysurf.fr>,
Scott Robert Ladd <coyote@coyotegulch.com>,
Robert Dewar <dewar@gnat.com>,
gcc@gcc.gnu.org, Nick Burrett <nick@dsvr.net>,
Gabriel Dos Reis <gdr@integrable-solutions.net>,
Marc Espie <espie@quatramaran.ens.fr>
Subject: Re: gcc 3.5 integration branch proposal
Date: Tue, 20 Jan 2004 20:41:00 -0000 [thread overview]
Message-ID: <ED167D66-4B88-11D8-B42C-003065A77310@apple.com> (raw)
In-Reply-To: <or8yk24f3l.fsf@free.redhat.lsd.ic.unicamp.br>
On Tuesday, January 20, 2004, at 11:03 AM, Alexandre Oliva wrote:
> Is the compiler server multi-threaded?
Nope.
> 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
a problem.
> 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
http://gcc.gnu.org/ml/gcc-patches/2003-03/msg00499.html Anyway,
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?
Yes.
> This might be nice, but it would probably be yet another incompatible
> change in the preprocessor output format that might cause problems to
> other tools.
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.
next prev parent reply other threads:[~2004-01-20 20:41 UTC|newest]
Thread overview: 185+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-10 0:11 Geoffrey Keating
2004-01-10 0:25 ` Phil Edwards
2004-01-10 0:47 ` Geoffrey Keating
2004-01-10 15:41 ` Phil Edwards
2004-01-12 18:47 ` Geoffrey Keating
2004-01-12 19:22 ` Mark Mitchell
2004-01-12 23:42 ` Geoff Keating
2004-01-12 23:48 ` Zack Weinberg
2004-01-12 23:49 ` Mark Mitchell
2004-01-13 0:06 ` Daniel Jacobowitz
2004-01-13 0:16 ` Daniel Jacobowitz
2004-01-13 0:22 ` Steven Bosscher
2004-01-13 19:48 ` Gerald Pfeifer
2004-01-13 0:28 ` Joe Buck
2004-01-13 0:46 ` Daniel Jacobowitz
2004-01-13 1:13 ` Jan Hubicka
2004-01-13 0:11 ` Ziemowit Laski
2004-01-13 0:15 ` Steven Bosscher
2004-01-13 0:23 ` Ziemowit Laski
2004-01-13 0:37 ` Steven Bosscher
2004-01-13 0:45 ` Jan Hubicka
2004-01-13 0:55 ` Ziemowit Laski
2004-01-13 0:54 ` Ziemowit Laski
2004-01-13 1:01 ` Mark Mitchell
2004-01-13 1:16 ` Ziemowit Laski
2004-01-13 1:26 ` Mark Mitchell
2004-01-13 1:33 ` Gabriel Dos Reis
2004-01-13 1:19 ` Gabriel Dos Reis
2004-01-13 0:47 ` Daniel Jacobowitz
2004-01-13 0:59 ` Altivec (Re: gcc 3.5 integration branch proposal) Matt Austern
2004-01-13 0:16 ` gcc 3.5 integration branch proposal Mark Mitchell
2004-01-13 0:54 ` Gabriel Dos Reis
2004-01-13 21:31 ` Geoff Keating
2004-01-13 22:41 ` David Edelsohn
2004-01-13 23:13 ` Daniel Berlin
2004-01-13 23:24 ` Paul Koning
2004-01-14 0:01 ` Geoff Keating
2004-01-14 0:26 ` Gabriel Dos Reis
2004-01-14 8:35 ` Laurent GUERBY
2004-01-14 14:58 ` Paul Koning
2004-01-13 23:29 ` Mike Stump
2004-01-14 0:47 ` Andrew Pinski
2004-01-14 1:05 ` Andrew Pinski
2004-01-14 1:36 ` Joe Buck
2004-01-14 19:47 ` Mike Stump
2004-01-13 23:51 ` Eric Christopher
2004-01-13 23:53 ` Daniel Berlin
2004-01-14 6:13 ` Mark Mitchell
2004-01-14 8:39 ` Laurent GUERBY
2004-01-14 8:48 ` Steven Bosscher
2004-01-14 20:59 ` Laurent GUERBY
2004-01-14 21:02 ` Andrew Haley
2004-01-19 1:31 ` Marc Espie
2004-01-19 1:51 ` Gabriel Dos Reis
2004-01-19 10:40 ` Nick Burrett
2004-01-19 13:55 ` Robert Dewar
2004-01-19 15:49 ` Gabriel Dos Reis
2004-01-19 16:09 ` Scott Robert Ladd
2004-01-19 16:24 ` Marc Espie
2004-01-19 17:07 ` Scott Robert Ladd
2004-01-19 17:54 ` Robert Dewar
2004-01-19 18:03 ` Gabriel Dos Reis
2004-01-19 17:41 ` Robert Dewar
2004-01-19 18:08 ` Scott Robert Ladd
2004-01-19 18:09 ` Scott Robert Ladd
2004-01-19 18:34 ` Marc Espie
2004-01-19 19:06 ` Robert Dewar
2004-01-19 20:22 ` Eric Botcazou
2004-01-19 20:38 ` Robert Dewar
2004-01-19 21:09 ` Eric Botcazou
2004-01-19 21:18 ` Eric Christopher
2004-01-19 21:46 ` Eric Botcazou
2004-01-19 22:09 ` Laurent GUERBY
2004-01-19 22:29 ` Marc Espie
2004-01-19 23:04 ` Laurent GUERBY
2004-01-20 3:45 ` Robert Dewar
2004-01-20 7:46 ` Marc Espie
2004-01-20 23:22 ` Gerald Pfeifer
2004-01-20 23:28 ` Zack Winkles
2004-01-19 23:53 ` Mark Hahn
2004-01-20 0:17 ` Gabriel Dos Reis
2004-01-20 14:27 ` Scott Robert Ladd
2004-01-22 14:50 ` Geoffrey Furnish
2004-01-20 6:27 ` gcc compilation speed Matt Austern
2004-01-20 7:23 ` Steven Bosscher
2004-01-20 7:40 ` Karel Gardas
2004-01-20 8:25 ` gcc 3.5 integration branch proposal Karel Gardas
2004-01-20 12:07 ` Laurent GUERBY
2004-01-20 14:41 ` Karel Gardas
2004-01-20 14:52 ` Daniel Berlin
2004-01-20 14:55 ` Karel Gardas
2004-01-20 15:16 ` Daniel Jacobowitz
2004-01-20 15:21 ` Karel Gardas
2004-01-20 16:16 ` Comparison of compilation speed of GCC 3.4.0 040114, ICC 8.0 and COMO 4.3.3 on MICO ORB core sources (C++) Karel Gardas
2004-01-20 15:08 ` gcc 3.5 integration branch proposal Paul Koning
2004-01-19 21:20 ` Robert Dewar
2004-01-20 2:05 ` Mike Stump
2004-01-20 14:25 ` Scott Robert Ladd
2004-01-19 21:34 ` Geoff Keating
2004-01-19 22:03 ` Eric Botcazou
2004-01-19 22:22 ` Geoff Keating
2004-01-19 22:38 ` Eric Botcazou
2004-01-20 3:53 ` Robert Dewar
2004-01-20 4:52 ` Eric Botcazou
2004-01-20 2:44 ` Alexandre Oliva
2004-01-20 3:04 ` Mike Stump
2004-01-20 19:03 ` Alexandre Oliva
2004-01-20 20:41 ` Mike Stump [this message]
2004-01-20 22:06 ` Alexandre Oliva
2004-01-20 22:59 ` Mike Stump
2004-01-20 18:52 ` Geoffrey Keating
2004-01-20 22:12 ` Alexandre Oliva
2004-01-20 22:30 ` Geoffrey Keating
2004-01-21 0:02 ` Alexandre Oliva
2004-01-21 12:12 ` Richard Earnshaw
2004-01-22 6:37 ` Segher Boessenkool
2004-01-22 10:38 ` Richard Earnshaw
2004-01-22 6:27 ` Segher Boessenkool
2004-01-26 18:55 ` compile speed [was: gcc 3.5 integration branch proposal] Per Bothner
2004-01-26 19:34 ` Alexandre Oliva
2004-01-20 0:01 ` GCC's hardware requirements - Where is the freedom? [was: " Matthias Benkmann
2004-01-20 3:13 ` Andrew Pinski
2004-01-20 3:17 ` Andrew Pinski
2004-01-20 9:23 ` Bernd Jendrissek
2004-01-20 21:38 ` Mike Stump
2004-01-20 22:50 ` Toon Moene
2004-01-20 8:12 ` Laurent GUERBY
2004-01-20 9:09 ` Eric Botcazou
2004-01-19 17:27 ` gcc 3.5 integration branch proposal Robert Dewar
2004-01-19 16:26 ` Per Bothner
2004-01-20 2:14 ` Mike Stump
2004-01-20 3:49 ` Zack Weinberg
2004-01-20 10:08 ` Jan Hubicka
2004-01-20 15:13 ` Daniel Jacobowitz
2004-01-20 18:04 ` Zack Weinberg
2004-01-20 18:48 ` Geoffrey Keating
2004-01-20 19:01 ` Zack Weinberg
2004-01-20 22:04 ` Geoff Keating
2004-01-21 2:23 ` Zack Weinberg
2004-01-22 6:27 ` Segher Boessenkool
2004-01-19 20:51 ` Dale Johannesen
2004-01-19 23:01 ` Gabriel Dos Reis
2004-01-19 3:42 ` Marc Espie
2004-01-19 3:47 ` Robert McNulty Junior
2004-01-19 3:49 ` David Edelsohn
2004-01-19 13:28 ` Marc Espie
2004-01-19 13:35 ` Jan Hubicka
2004-01-19 19:10 ` Marc Espie
2004-01-19 19:15 ` Marc Espie
2004-01-19 20:49 ` Diego Novillo
2004-01-19 19:39 ` Jan Hubicka
2004-01-19 13:35 ` Diego Novillo
2004-01-19 13:39 ` Jan Hubicka
2004-01-19 17:58 ` Jan Hubicka
2004-01-19 3:59 ` Zack Weinberg
2004-01-19 8:19 ` Steven Bosscher
2004-01-19 11:29 ` Jan Hubicka
2004-01-19 13:18 ` Jan Hubicka
2004-01-19 14:13 ` Robert Dewar
2004-01-19 14:18 ` Jan Hubicka
2004-01-19 14:48 ` Vladimir Makarov
2004-01-19 17:04 ` Jan Hubicka
2004-01-20 2:46 ` Alexandre Oliva
2004-01-19 4:37 ` Giovanni Bajo
2004-01-19 4:46 ` Gabriel Dos Reis
2004-01-19 7:04 ` Eric Botcazou
2004-01-19 7:10 ` Andreas Jaeger
2004-01-19 8:12 ` Steven Bosscher
2004-01-19 8:38 ` Gabriel Dos Reis
2004-01-19 8:45 ` Steven Bosscher
2004-01-19 9:35 ` Gabriel Dos Reis
2004-01-12 22:40 ` Mike Stump
2004-01-13 23:31 Michael Elizabeth Chastain
2004-01-19 16:24 Paul Koning
2004-01-19 17:46 ` Robert Dewar
2004-01-19 17:51 ` Gabriel Dos Reis
2004-01-19 18:12 ` Scott Robert Ladd
2004-01-19 18:20 ` Gabriel Dos Reis
2004-01-19 18:29 ` Giovanni Bajo
2004-01-19 18:22 ` Robert Dewar
2004-01-19 18:30 ` Paul Koning
2004-01-20 10:46 ` Russ Allbery
2004-01-20 3:00 D. Starner
2004-01-20 3:14 ` Andrew Pinski
2004-01-20 5:19 D. Starner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ED167D66-4B88-11D8-B42C-003065A77310@apple.com \
--to=mrs@apple.com \
--cc=aoliva@redhat.com \
--cc=coyote@coyotegulch.com \
--cc=dewar@gnat.com \
--cc=ebotcazou@libertysurf.fr \
--cc=espie@quatramaran.ens.fr \
--cc=gcc@gcc.gnu.org \
--cc=gdr@integrable-solutions.net \
--cc=geoffk@apple.com \
--cc=nick@dsvr.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).