From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7093 invoked by alias); 20 Jan 2004 20:41:06 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 7071 invoked from network); 20 Jan 2004 20:41:05 -0000 Received: from unknown (HELO mail-out3.apple.com) (17.254.13.22) by sources.redhat.com with SMTP; 20 Jan 2004 20:41:05 -0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.10/8.12.9) with ESMTP id i0KKf4nM024604 for ; Tue, 20 Jan 2004 12:41:04 -0800 (PST) Received: from relay3.apple.com (relay3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id ; Tue, 20 Jan 2004 12:41:04 -0800 Received: from apple.com (mrs1.apple.com [17.201.24.248]) by relay3.apple.com (8.12.10/8.12.9) with ESMTP id i0KKelN7029787; Tue, 20 Jan 2004 20:40:48 GMT Date: Tue, 20 Jan 2004 20:41:00 -0000 Subject: Re: gcc 3.5 integration branch proposal Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Geoff Keating , Eric Botcazou , Scott Robert Ladd , Robert Dewar , gcc@gcc.gnu.org, Nick Burrett , Gabriel Dos Reis , Marc Espie To: Alexandre Oliva From: Mike Stump In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-SW-Source: 2004-01/txt/msg01556.txt.bz2 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.