Re: GCC 3.3

[Gerald Pfeifer <pfeifer at dbai dot tuwien dot ac dot at>]

On Tue, 29 Apr 2003, Steven Bosscher wrote:
>> What about compile-time regressions?
> Seems a bit too late to try and take care of that now, don't you think?
>
> Gerald and others have shown, there is no single patch or a small set of
> patches that we can blame the slowdown on; instead GCC consistently
> slowed down over a period that spans at least two years: 3.2 was slower
> than 3.1, which in turn was slower than 3.0, etc.

There are two major sources of frustration here, affecting at least me
(as a user) and Mark (as maintainer and release manager).

> So those compile time regressions will not be fixed in a matter of days,
> and weeks or months seems unacceptable.  Let's please just put out 3.3
> and move on to make 3.4 a much better (includes: faster) compiler than
> 3.3.

1. I reported these performance regressions before the release of GCC 3.0,
   about two years ago

     http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=3083

   and spent a significant amount of time (surely several man days)
   following this issue, as have others including yourself and Kaveh).

   Still, now close to GCC 3.3, the situation is as bad as:

      http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=8361

                    -O0         -O1          -O2        -O3
       GCC 3.0.4    27.95       44.52        56.57      56.48
      3.2-branch    29.87 +7%   54.28 +22%   70.95 +25% 75.29 +33%
      3.3-branch    29.09 +4%   57.11 +30%   78.99 +40% 81.61 +44%

   (and this completely ignores GCC 2.95, which was _vastly_ faster).

   > Only C++ really is somewhat slower.

   That's an euphemism.

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).

Obviously, the picture is not as simple as drafted above, many others have
contributed most welcome performance improvements (even if in the end, we
lost), and some of the slowdowns were for correctness and optimization
(even if neither applied to my code at least).

Gerald
-- 
Gerald "Jerry"   pfeifer@dbai.tuwien.ac.at   http://www.pfeifer.com/gerald/