From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4054 invoked by alias); 3 Sep 2002 17:32:55 -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 4047 invoked from network); 3 Sep 2002 17:32:54 -0000 Received: from unknown (HELO mail-out2.apple.com) (17.254.0.51) by sources.redhat.com with SMTP; 3 Sep 2002 17:32:54 -0000 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g83HWs500360 for ; Tue, 3 Sep 2002 10:32:54 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 3 Sep 2002 10:32:46 -0700 Received: from johada.apple.com (johada.apple.com [17.201.20.167]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id g83HWj300917; Tue, 3 Sep 2002 10:32:45 -0700 (PDT) Date: Tue, 03 Sep 2002 10:32:00 -0000 Subject: Re: [GCC 3.x] Performance testing for QA Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) Cc: Dale Johannesen , tjw@omnigroup.com, Peter.Sasi@t-systems.co.hu, aj@suse.de, gcc@gcc.gnu.org To: dewar@gnat.com (Robert Dewar) From: Dale Johannesen In-Reply-To: <20020902224940.E7865F2D75@nile.gnat.com> Message-Id: <279B0E74-BF63-11D6-A404-003065C86F94@apple.com> Content-Transfer-Encoding: 7bit X-SW-Source: 2002-09/txt/msg00091.txt.bz2 On Monday, September 2, 2002, at 03:49 PM, Robert Dewar wrote: > << I only reason I think its nice to have the compiler bootstrap as > part > of the benchmark is to make sure that the compiler is fast. Instead, I > think it would be more interesting to see how fast the compiler could > build all the other benchmarks -- not how fast it could build itself :) >>> > > I disagree, gcc is a very interesting benchmark because of its locality > patterns. It precisely is NOT a collection of tight loops, and unlike > some of the other tests in SPEC, it is very hard to tune a compiler > to do artifically well on the gcc benchmark. Since the benchmark gcc is never fed any erroneous source while running the benchmark, none of the error-handling stuff is ever executed. With profile-based optimization it's possible to move a lot of that stuff so it never gets paged in; that's a significant win. The same conditions don't apply when running gcc normally, so this is fairly artificial.