From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24279 invoked by alias); 2 Sep 2002 22:49: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 24272 invoked from network); 2 Sep 2002 22:49:41 -0000 Received: from unknown (HELO nile.gnat.com) (205.232.38.5) by sources.redhat.com with SMTP; 2 Sep 2002 22:49:41 -0000 Received: by nile.gnat.com (Postfix, from userid 338) id E7865F2D75; Mon, 2 Sep 2002 18:49:40 -0400 (EDT) To: dewar@gnat.com, tjw@omnigroup.com Subject: Re: [GCC 3.x] Performance testing for QA Cc: Peter.Sasi@t-systems.co.hu, aj@suse.de, gcc@gcc.gnu.org Message-Id: <20020902224940.E7865F2D75@nile.gnat.com> Date: Mon, 02 Sep 2002 15:49:00 -0000 From: dewar@gnat.com (Robert Dewar) X-SW-Source: 2002-09/txt/msg00043.txt.bz2 << 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. Of course you want a big collection of benchmarks, and actually we advise users of GNAT to always test on their own code rather than benchmarks, but GCC is probably one of the better benchmarks around. The trouble with the encoder/decoder examples is that they tend to concentrate on specific inner loops. That means that they are much more open to subversion (although interestingly, GCC is probably the one compiler where there is NOT a lot of effort spent specifically on getting benchmarks to work better).