From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24887 invoked by alias); 3 Feb 2003 21:54:41 -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 24877 invoked from network); 3 Feb 2003 21:54:40 -0000 Received: from unknown (HELO mail-out1.apple.com) (17.254.0.52) by 172.16.49.205 with SMTP; 3 Feb 2003 21:54:40 -0000 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id h13Lsd129359 for ; Mon, 3 Feb 2003 13:54:39 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 3 Feb 2003 13:54:34 -0800 Received: from apple.com (goldte.apple.com [17.201.21.104]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id h13LsXQ15575; Mon, 3 Feb 2003 13:54:33 -0800 (PST) Date: Mon, 03 Feb 2003 21:54:00 -0000 Subject: Re: GCC 3.3, GCC 3.4 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Devang Patel , gcc@gcc.gnu.org, Matt Austern To: Tim Josling From: Devang Patel In-Reply-To: <3E3E226F.1DA63EDF@melbpc.org.au> Message-Id: <14035A2A-37C2-11D7-8C5C-0003935AAA26@apple.com> Content-Transfer-Encoding: 7bit X-SW-Source: 2003-02/txt/msg00137.txt.bz2 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. -Devang