FACTS instead of FUD about gcc3

Ian Molton spyro at armlinux.org
Wed May 8 09:19:56 PDT 2002


On Wed, 8 May 2002 16:41:59 +0200
Matthias Benkmann <matthias at winterdrache.de> wrote:

> After reading a 2nd-hand account about GCC3's 20% performance
> regression I thought you might be interested in the actual facts.

Er. theres nothing below I didnt mention.

And bear in mind that aside from media processing, 90% or more
operations are integer based.

Its great that the problem can be worked around, but we shouldnt use
something until the problems are FIXED, or we should provide patches for
all the regressions it causes in other packages (unrealistic).


----- below left in for completeness -----

? I
> quote below excerpts from the 1st and last message of the reporter of
> the issue. You can find them archived in full at
> 
> http://gcc.gnu.org/ml/gcc/2002-04/msg01013.html
> 
> and
> 
> http://gcc.gnu.org/ml/gcc/2002-04/msg01194.html
> 
> Note: I added ***...*** for emphasis around important (IMHO) phrases.
> 
>      From: Michel LESPINASSE <walken at zoy dot org>
>      Date: Sat, 20 Apr 2002 17:57:18 -0700
>      Subject: GCC performance regression - up to 20% ?
> 
> I have downloaded the latest 3.1 snapshot (20020415) and ran some
> performance tests. So far I've been ***impressed by the FP
> performance***, but kinda ***disappointed by the integer
> performance***.
> 
> The benchmarks I've run are two libraries I maintain, libmpeg2 and
> liba52:
> 
> First the ***good news***: liba52 (mostly FP intensive workload)
> on athlon tbird 950, using -mcpu=pentiumpro:
> gcc-3.1 snapshot is between ***8% and 9.5% faster*** than 2.95.4
> from these measurements 3.1 has a very nice performance, very close to
> intel's icc. Great work ! Also using -march=athlon-tbird and
> generating sse code, I can get yet a few extra % of performance.
> 
> Now the ***bad news***: for libmepg2, which is an integer-only
> workload, I get a ***10% to 20% performance regression*** between
> 2.95.4 and 3.1...
> 
> libmpeg2, on celeron 366, with mmx optimizations:
> gcc-3.0 is about 4% slower than 2.95.4
> gcc-3.1 snapshot is about ***20.5% slower*** than 2.95.4 (!!!!)
> 
> 
>     From: Michel LESPINASSE <walken at zoy dot org>
>     Date: Tue, 23 Apr 2002 13:35:26 -0700
>     Subject: Re: GCC performance regression - its memset !
> 
> On Tue, Apr 23, 2002 at 11:25:40AM +0200, Jan Hubicka wrote:
> 
> > Concerning the inlining, gcc inlines all memcpys with size smaller
> > than 64 bytes. Perhaps this should be extended to 128 bytes in case
> > we are still about 2 times as bad. This is 
> > ***partly due to lame implementation of memset in glibc too*** :(
> 
> 
> Also as I've been only giving bad news up to now, I wanted to say that
> now that I've worked around the two issues I had with inlining and
> with memset, the 3.1 snapshot does provide ***superior performance on
> my libmpeg2*** codebase, about 5% faster than 2.95.4, and that gets up
> to 8% when using -fbranch-probabilities and 9% when using
> -mcpu=athlon-tbird instead of the more generic -mcpu=pentiumpro. Nice
> work guys !
> 
> 
> MSB
> -- 
> If Barbie is so popular, why do you have to buy her friends?
> 
> -- 
> Unsubscribe: send email to listar at linuxfromscratch.org
> and put 'unsubscribe lfs-dev' in the subject header of the message
> 
-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message



More information about the lfs-dev mailing list