This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: We're out of tree codes; now what?
In article <24b520d20703191627v257c60ffw8bc96c5f73b1e789@mail.gmail.com> you write:
>On 19 Mar 2007 19:12:35 -0500, Gabriel Dos Reis <gdr@cs.tamu.edu> wrote:
>> similar justifications for yet another small% of slowdown have been
>> given routinely for over 5 years now. small% build up; and when they
>> build up, they don't not to be convincing ;-)
>
>But what is the solution? We can complain about performance all we
>want (and we all love to do this), but without a plan to fix it we're
>just wasting effort. Shall we reject every patch that causes a slow
>down? Hold up releases if they are slower than their predecessors?
>Stop work on extensions, optimizations, and bug fixes until we get our
>compile-time performance back to some predetermined level?
Simple sociology.
Working on new optimizations = sexy.
Trimming down excess weight = unsexy.
GCC being vastly a volunteer project, it's much easier to find people
who want to work on their pet project, and implement a recent
optimization they found in a nice paper (that will gain 0.5% in some
awkward case) than to try to track down speed-downs and to reverse them.
I remember back then when people started converting gcc from RTL to ssa,
I was truely excited. Finally doing the right thing, compile times
are going to get back down where they belong.
And then disappointment, as the ssa stuff just got added on top of the
RTL stuff, and the RTL stuff that was supposed to vanish takes forever
to go away...
Parts of GCC are over-engineered. I used to be able to read the
__attribute__ stuff, then it got refactored, and the new code looks like
it's going to be about 3 or 4 times slower than it was.
At some point, it's going to be really attractive to start again from
scratch, without all the backends/frontend complexities and interactions
that make cleaning up stuff harder and harder...
Also, I have the feeling that quite a few of gcc sponsors are in it for
the publicity mostly (oh look, we're nice people giving money to gcc),
and new optimization passes that get 0.02% out of SPEC are better bang
for their money.
Kuddoes go to the people who actually manage to reverse some of the
excesses of the new passes.