From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14568 invoked by alias); 3 Feb 2003 22:32:12 -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 14554 invoked from network); 3 Feb 2003 22:32:12 -0000 Received: from unknown (HELO desire.geoffk.org) (12.235.57.148) by 172.16.49.205 with SMTP; 3 Feb 2003 22:32:12 -0000 Received: (from geoffk@localhost) by desire.geoffk.org (8.11.6/8.11.6) id h13MUmo13674; Mon, 3 Feb 2003 14:30:48 -0800 X-Authentication-Warning: desire.geoffk.org: geoffk set sender to geoffk@geoffk.org using -f To: Devang Patel Cc: gcc@gcc.gnu.org, Matt Austern Subject: Re: GCC 3.3, GCC 3.4 References: <3E3E226F.1DA63EDF@melbpc.org.au> <14035A2A-37C2-11D7-8C5C-0003935AAA26@apple.com> From: Geoff Keating Date: Mon, 03 Feb 2003 22:32:00 -0000 In-Reply-To: <14035A2A-37C2-11D7-8C5C-0003935AAA26@apple.com> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-02/txt/msg00143.txt.bz2 Devang Patel writes: > On Monday, February 3, 2003, at 12:04 AM, Tim Josling wrote: > > > > >> On Thursday, January 30, 2003, at 03:38 PM, Neil Booth wrote: > >>> I'm interested in improving the quality of GCC. Your statment above > >>> indicates you're interested in pointing to a number and saying "look, > >>> it's lower", regardless of what that means long-term. Hell, let's > >>> not free anything at all and turn GC off altogether; GCC would be > >>> faster > >>> for 90% of files I imagine. > >> > >> Guess what? For smaller programs, it already does that! So, you are > >> just describing status quo. > > > > It is one thing to stop collecting; it is another to turn off GC. > > > > Tests I did last year showed that even without doing collection, gcc > > is slowed > > down by the requirements of GC: > > > > 1. Allocating storage of similar sizes together, sacrificing locality. > > 2. Wasting space by rounding up allocations to the next power of 2, > > wasting > > space and increasing working set sizes. > > 3. Having bits of GC code all over the place impacting code locality > > and > > working set sizes. > > > > Turning off GC slows down the part of the build of GCC attributable > > to the > > xgcc/cc1/ld by 5%. > > > > However removing it and allocating sequentially (each allocation is > > next to > > the previous one) reduces build xgcc/cc1/ld compile time by about 5%. > > > > Add these together and the requirements of GC slow down the compiler > > by about > > 10% (though collecting gets half of it back)! And most compiles > > don't need or > > benefit from it! > > Matt Austern at Apple did similar experiment by using ggc placeholder. > (same interface as ggc, no collection, allocate memory using mmap in > chunks and > satisfy memory allocation requests from these chunks etc..). > > He got around ~12% speedup for sample c++ source. To be precise, Matt found that the speedup of using the ggc placeholder was about equivalent to the speedup of using ggc-page but disabling garbage collection. This contradicts the results that Tim Josling got above. -- - Geoffrey Keating