Re: GCC 3.0 Status Report

[Geoff Keating <geoffk at geoffk dot org>]

Mark Mitchell <mark@codesourcery.com> writes:

>   In the short term, we will focus on compile-time performance, 
>   especially in C++.  At that point, application testing will 
>   become the major focus.  Performance of the generated code
>   will be a greater focus of the 3.1 release.

Hi Mark,

I have some news for you, which might be good or might be bad, your
choice :-).

Jason Merrill took over the PCH stuff from where I left it, and
finished the C++ support.  Based on the numbers I had for C, I
expected a 2x or 3x speed improvement, which is nice but not
earth-shattering.  However, we have some new numbers from Daniel
Berlin which indicates that the speed improvement is more on the order
of 20x, when compiling KDE; I guess I just didn't realize how huge C++
headers were.  Dan says 'I can now compile all of KDE in the time it
took to compile one file before'.

I think this is such a significant improvement that it makes
consideration of compile-time improvements in the current compiler
much less important.  Of course, a 20% increase is still a significant
increase, but I expect the profile of GCC with PCH to be different to
that for GCC without PCH, and so it might be that a 5% increase goes
turns out to be a .5% increase.  I don't think anyone has tried tuning
the PCH code for performance yet, for instance, and there are a bunch
of places where I noted a possible speed problem when I was writing it
and designed the code so that if it became a problem it could easily
be improved.

The state of this code is that we're just about to ship it to the
customer.  We've stopped finding bugs in it, but probably only because
we've run out of things we know to test.  It basically works, but
there's still significant work to do before it's really finished, in
particular there's a lot of duplicated functionality between the PCH
code and the GC code.  We could put it into FSF GCC right now, at the
cost of some instability, but it's not tested enough to be in the 3.0
release.  Also, the customer hasn't accepted the release yet, and we
don't usually submit stuff until it's paid for, at least not all of
it, and I expect final acceptance for this code to take longer than
usual not least of which because I expect the customer to try it on
their sources and find lots of bugs.

So my proposal is that compile-time performance for the 3.0 release be
downgraded in importance; that we move as much as possible of PCH into
the mainline FSF tree as soon as possible, so that others can work on
it and so that it can be integrated into the 3.1 release; and that the
main feature of the 3.1 release will be compile-time speed
improvements, much of which will be provided by precompiled headers.

Of course, there are some things that could be done that would speed
up 3.0 and speed up PCH even more; for instance, GC is one of the
things that take more time with PCH because PCH creates lots of
permanent objects right at the start of compilation, so improvements
to how GC handles permanent objects will be a big win.

-- 
- Geoffrey Keating <geoffk@geoffk.org>