This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 3.3
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Gerald Pfeifer <pfeifer at dbai dot tuwien dot ac dot at>
- Cc: gcc at gcc dot gnu dot org, Steven Bosscher <s dot bosscher at student dot tudelft dot nl>, "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Date: 30 Apr 2003 22:00:35 -0700
- Subject: Re: GCC 3.3
- Organization: CodeSourcery, LLC
- References: <1051588103.8343.880.camel@doubledemon.codesourcery.com> <200304291444.KAA19733@caip.rutgers.edu> <1051633670.8343.938.camel@doubledemon.codesourcery.com> <Pine.BSF.4.53.0304301842380.39433@naos.dbai.tuwien.ac.at>
> 2. Mark _has_ contributed quite a couple of performance improvements,
> (and so have others).
>
> But just because he is release manager and C++ maintainer, nobody can
> sensibly demand that he fixes all performance issues showing up from
> C++ code by himself; even more so if many advances of his are more
> than offset by the creeping slowdown throughout the compiler.
>
> So, in the end, I suppose that currently both Mark and myself are somehow
> frustrated (at least that's how I understood his reply).
I just don't think that we're going to be able to fix this for 3.3 given
where we presently are.
In practice, we often have a hard time getting people to fix correctness
regressions that they have introduced; compile-time regressions will be
even tougher, and they're tougher to pin on a particular person. If I
fix a bug, but introduce a 0.25% slowdown, is that a net win or not?
What if I speed up some piece of generated code by 1%? When we still
have quadratic algorithms in the compiler, should we worry about my
0.25% slowdown? Maybe we should invest in fixing those algorithms
instead -- but that requires major work, and we can't expect someone
who's just fixing a bug somewhere to do that.
The good news is that LANL is interested in seeing the C++ compiler run
faster, so Zack and Nathan and I *are* looking at these issues, from a
variety of different angles.
We are lucky in that LANL and Apple (among others, perhaps) are actively
supporting improvements in this area.
I remain hopeful.
--
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC