From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29998 invoked by alias); 29 Nov 2004 16:29:49 -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 29794 invoked from network); 29 Nov 2004 16:29:40 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 29 Nov 2004 16:29:40 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id iATGTeAt022041; Mon, 29 Nov 2004 11:29:40 -0500 Received: from redhat.com (wcohen.devel.redhat.com [172.16.56.117]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id iATGTer03582; Mon, 29 Nov 2004 11:29:40 -0500 Message-ID: <41AB4E74.8010103@redhat.com> Date: Mon, 29 Nov 2004 16:30:00 -0000 From: Will Cohen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.3) Gecko/20040924 MIME-Version: 1.0 To: Dan Kegel CC: law@redhat.com, GCC Mailing List , bastian@kde.org Subject: Re: profile-driven optimization and the linker? References: <41A620F5.5040209@kegel.com> <1101412168.13475.19.camel@localhost.localdomain> <41A63996.1020407@kegel.com> <1101419643.13475.69.camel@localhost.localdomain> <41A6AC41.7000305@kegel.com> In-Reply-To: <41A6AC41.7000305@kegel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-11/txt/msg01130.txt.bz2 Dan Kegel wrote: > > http://gcc.gnu.org/ml/gcc-patches/2001-11/msg00935.html says > "Steve Christiansen tried using gprof output to create a linker > script that orders functions based on run-time call graphs > and call counts, but couldn't show that it made a difference, based on > SPEC CPU2000 results." > (Since the --function-ordering option was added to gprof at > the end of 1995, I imagine Steve Christiansen used it. > On the other hand, since glibc aborted with more > than 64K symbols when run with -pg until late 2002, > maybe he ran into trouble there.) SPEC CPU2000 is not likely to be a big winner for reordering fuctions. There are small sections of code that consume most of the excution time for most of the benchmarks. Bigger winners are going to be code where things do not fit neatly into a cache or a limited number of pages, e.g. code using many shared libraries. On some versions of the Pentium III there are only 32 instruction TLB entries, each for a 4K page. That isn't going to go very far when there are over 100 shared libraries mapped as in the case of openoffice. Each library has to be on a separate page. -Will