From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27965 invoked by alias); 3 Sep 2002 18:17:07 -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 27958 invoked from network); 3 Sep 2002 18:17:04 -0000 Received: from unknown (HELO master.atkinson.dhs.org) (68.55.217.208) by sources.redhat.com with SMTP; 3 Sep 2002 18:17:04 -0000 Received: from kevin-pc.atkinson.dhs.org (kevin-pc.atkinson.dhs.org [192.168.1.3]) by master.atkinson.dhs.org (Postfix) with ESMTP id 4E192BA2F; Tue, 3 Sep 2002 14:17:04 -0400 (EDT) Date: Tue, 03 Sep 2002 11:17:00 -0000 From: Kevin Atkinson X-X-Sender: kevina@kevin-pc.atkinson.dhs.org To: Robert Dewar Cc: tjw@omnigroup.com, , , Subject: Re: [GCC 3.x] Performance testing for QA In-Reply-To: <20020902224940.E7865F2D75@nile.gnat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-09/txt/msg00093.txt.bz2 On Mon, 2 Sep 2002, Robert Dewar wrote: > 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). However, encoding/decoding (especially encoding) is one area were speed really matters. Encoding in real time (with out sacrificing quality) is still not passable with many codecs except on the newest machines. Unfortunately, because video work is so computationally extensive significant portions of the code are often rewritten is assembly to take advantage of MMX etc instructions that many compilers do not produce normally. This means that that pure C versions may not exist or if they do they are not coded optimally. For example my PIII 500 is fast enough for me for most of my work but when I need to do video work I use my family P4. --- http://kevin.atkinson.dhs.org