From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2356 invoked by alias); 17 May 2007 19:57:03 -0000 Received: (qmail 2338 invoked by uid 22791); 17 May 2007 19:56:59 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 17 May 2007 19:56:55 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l4HJtkED005682; Thu, 17 May 2007 15:55:47 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l4HJtkoe002160; Thu, 17 May 2007 15:55:46 -0400 Received: from free.oliva.athome.lsd.ic.unicamp.br (vpn-14-148.rdu.redhat.com [10.11.14.148]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l4HJti8Z024834; Thu, 17 May 2007 15:55:45 -0400 Received: from free.oliva.athome.lsd.ic.unicamp.br (localhost.localdomain [127.0.0.1]) by free.oliva.athome.lsd.ic.unicamp.br (8.14.1/8.13.8) with ESMTP id l4HJtg7K022596; Thu, 17 May 2007 16:55:42 -0300 Received: (from aoliva@localhost) by free.oliva.athome.lsd.ic.unicamp.br (8.14.1/8.13.5/Submit) id l4HJtgNQ022592; Thu, 17 May 2007 16:55:42 -0300 To: "Daniel Berlin" Cc: "Mike Stump" , "Ian Lance Taylor" , "Mark Mitchell" , "Zdenek Dvorak" , gcc-patches@gcc.gnu.org Subject: Re: [patch] Move loop structures to gc memory References: <20070513180823.GA25352@kam.mff.cuni.cz> <20070514230252.GA27051@caradoc.them.org> <20070515021402.GA3168@caradoc.them.org> <464A5CCB.4020000@codesourcery.com> <4aca3dc20705160854o5336457eua905c36296da9bd3@mail.gmail.com> <4aca3dc20705171038ye54e4e7s5bd76f082a2a8a2c@mail.gmail.com> From: Alexandre Oliva Errors-To: aoliva@oliva.athome.lsd.ic.unicamp.br Date: Thu, 17 May 2007 19:57:00 -0000 In-Reply-To: <4aca3dc20705171038ye54e4e7s5bd76f082a2a8a2c@mail.gmail.com> (Daniel Berlin's message of "Thu\, 17 May 2007 13\:38\:30 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.95 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2007-05/txt/msg01151.txt.bz2 On May 17, 2007, "Daniel Berlin" wrote: > On 5/17/07, Mike Stump wrote: >> On May 16, 2007, at 5:47 PM, Ian Lance Taylor wrote: >> > Putting something in GC memory unnecessarily is inevitably slower than >> > not putting it in GC memory, if only because GC requires overhead to >> > track objects. >> But, the cost can be as cheap as: > It's not that cheap right now. > Unless you are going to make it this cheap, can we please stop > pretending it's this cheap? This argument seems backwards. If our GC memory allocator is slow, this affects *every* call of ggc_alloc. Moving objects out of the GC pool because ggc_alloc is slow is a local, limited fix, that merely papers over the real problem. It seems quite obvious to me that speeding up ggc_alloc such that it's on par with other, faster allocators, would achieve not only the intended benefit of moving objects out of GC (except for alloca(), which is truly unbeatable), but also speed everything else up. Surely it is possible to allocate memory faster, since other allocators do it, and it's not like doing so in a GC-enabling way requires significant overhead. Then why paper over the problem that slows all of GCC down? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}