[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc
Subject:    Re: GCC 3.3 compile speed regression - THE GRAPH
From:       Marc Espie <espie () quatramaran ! ens ! fr>
Date:       2003-02-09 17:45:22
[Download RAW message or body]

In article <20030207221424.GC17153@daikokuya.co.uk> you write:
>Ziemowit Laski wrote:-

>> I've already spoken with Geoff regarding his fateful PCH merge.  He did 
>> not think
>> that doing a binary search on the pch-branch would be particularly 
>> productive,
>> but instead suggested I look closely at his spew.c mods, which I shall 
>> do now.

>spew.c is dead in 3.4, so this would only be useful for 3.3.  I suggest
>you spend your time on something else.

>Neil.

You're going to say I'm always beating the same dead horse, but I believe
this is THE stem of all of gcc's performance problems: 

the next version is always going to be better.  

I've heard this at least ten times since 2.95 came out (between the gc for 
stability -> flush speed out the window..  now it's pch, which is going to 
be only in 3.4), and in reality, the current stable release always is pretty 
bad, speed-wise, but who cares ?

the next release is going to be better...


After a few releases, it gets really hard to believe how the next release
is going to be better, since reality seems to prove otherwise.

And there you have the conundrum for distribution builders: each new release
of gcc has marked improvemtns in some areas, and marked losses in some others,
so it is fairly difficult to choose.  Especially when you're not building
for mainstream environment... 

The latest `improvement' in the release process seems to me of the 
`sweep issues under the carpet' nature: mark as regression stuff that is
a regression over the last immediate release, and more or less ignore less
recent problems that did not exist in, say, gcc 2.95.3.

In the end, because there is no definite win in upgrading, various people
stay with various versions of gcc (for instance, OpenBSD will stay stuck
with 2.95.x until the compiler's speed markedly improves), thus dispersing
forces, handling lots more bug-reports than could happen otherwise...

And yes, the speed issue can be solved by cross-compiling. Unfortunately,
this is also the last nail in the coffin for old, slow architectures. Think
about it: if you start cross-compiling everything, you are getting rid of a
very good stress test (compiling the whole system), and thus help some bugs
not getting noticed...
[prev in list] [next in list] [prev in thread] [next in thread]