From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-51723-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 7465 invoked by alias); 9 May 2002 13:37:51 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 7451 invoked from network); 9 May 2002 13:37:50 -0000
Received: from unknown (HELO fencepost.gnu.org) (199.232.76.164)
  by sources.redhat.com with SMTP; 9 May 2002 13:37:50 -0000
Received: from atrey.karlin.mff.cuni.cz ([195.113.31.123])
	by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian))
	id 175o7B-0001Jl-00
	for <gcc@gnu.org>; Thu, 09 May 2002 09:37:49 -0400
Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 4018)
	id 501F74FCC3; Thu,  9 May 2002 15:37:50 +0200 (CEST)
Date: Thu, 09 May 2002 07:04:00 -0000
From: Jan Hubicka <jh@suse.cz>
To: Scott Robert Ladd <scott@coyotegulch.com>
Cc: Jan Hubicka <jh@suse.cz>, "Gcc@Gnu. Org" <gcc@gnu.org>
Subject: Re: Benchmarks gcc 3.0.4 (soon 3.1) vs. Intel C++ 6.0
Message-ID: <20020509133750.GA27909@atrey.karlin.mff.cuni.cz>
References: <20020509130343.GX19486@atrey.karlin.mff.cuni.cz> <FKEAJLBKJCGBDJJIPJLJKEOICFAA.scott@coyotegulch.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <FKEAJLBKJCGBDJJIPJLJKEOICFAA.scott@coyotegulch.com>
User-Agent: Mutt/1.3.27i
X-SW-Source: 2002-05/txt/msg00651.txt.bz2

> HI,
> 
> I asked RedHat's Richard Henderson about which options I should use for
> getting the fastest code from gcc; he only suggested -O2. In fact, he wasn't
> real hot on -O3 (which I used) because he thought it might slow code down
> through bloat.

It depends on the nature of code you do use.
Using -O2 results in overall best resuts, as it does not trade too much of code
size for speed, but in case of code with small internal loops unrolling helps,
similary for code with many function calls inlining helps.
Your code generally seems to stress abstraction penalty or contain small loops.

You may take a look at http://www.suse.de/~aj/SPEC for study of effect of
various switches on gcc 3.0.0 and SPEC benchmark.

Note that comparing gcc to Intel C++, Intel C++ seems to win for numeric code,
while for integer code, the results are usually much more balanced.

Honza
> 
> I am looking into this further; I hope to have an updated comparison,
> including reader comments, over the weekend.
> 
> ..Scott
> 
> > -----Original Message-----
> > From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org]On Behalf Of
> > Jan Hubicka
> > Sent: Thursday, May 09, 2002 09:04
> > To: Scott Robert Ladd
> > Cc: Gcc@Gnu. Org
> > Subject: Re: Benchmarks gcc 3.0.4 (soon 3.1) vs. Intel C++ 6.0
> >
> >
> > > Hello, all,
> > >
> > > I've posted a set of benchmarks comparing the performance of
> > code generated
> > > by gcc 3.0.4 against that generated by Intel C++ 6.0 for Linux:
> > >
> > > http://www.coyotegulch.com/reviews/intel_comp/intel_gcc_bench2.html
> >
> > Interesting comparison..
> > Would you please try how does
> > -funroll-loops/-funroll-all-loops/-fomit-frame-pointer/-ffast-math
> >  change the
> > picture?  Also you may grab the 3.1.0 prerelease available already and use
> > it for benchmarking.
> >
> > Honza
> > >
> > > Please read the entire article before drawing any conclusions.
> > >
> > > Scott Robert Ladd
> > > Coyote Gulch Productions,  http://www.coyotegulch.com
> > > No ads -- just very free (and somewhat unusual) code.
> >