Re: A quick summary of gcc compilation speed from a political point of view

[Jan Hubicka <hubicka at ucw dot cz>]

> >From the little discussion that I inadvertently started, I believe I can
> start to draw conclusions.
> 
> There is a large number of people who apparently do not care at all that
> gcc is getting slower, because they say that we can buy faster hardware,
> and gcc is not getting slower THAT fast.
> 
> If that's the consensus, it would be a good idea to seriously amend the
> GCC description.
Mark,

it is definitly not concensus and what I wanted to point out by my
little kernel compilation benchmark is that the situation is now taken
quite seriously and the compiler is _not_ getting slower with each
release anymore. All GCC developers noticed that compile time
performance is important and it is now common to provide compilation
time infromation for each change and try hard to minimize the compile
time costs.

The fact that we see comparable speeds in between 3.2.0 done about two
years go and today is kind of sucess, especially if you compare it with
regular slowdown in between release in the past.  We clearly can try
harder and do better.

There is little value from sending desperate emails once new version has
been feature freezed and there is little that can be do to fact twofold
slowodn relative to 2.95.  In the case the perofmrance is really dear to
you, there are many ways you can help to improve it for future releases.

For instance, providing way to test the changes can be very cool.  You
can take a look at graphs at http://www.suse.de/~aj/SPEC.  At the day
Diego and Andreas started the testers, the code quality started to
improve.  Similarly we do have CSiBE benchmarks for code size that are
very usefull.

Also when I started to work on cgraph code I wasn't interested in
solving the C++ inliner problem as I hardly ever use C++, but the fact
that Gerald provided a good testcases, benchmark and a lot of assistance
it made it challenging and seemingly important project for me and I
spent about 5 months working on C++ frontend and other areas I never was
interested before.

Problem of performance is that each idividual change makes too little
effect on compiler to be measurable in isolation and many changes cause
disaster.  If we had good way to measure the factors such as memory
usage or page faults, we would know better how to look at.

So parhaps you can work with GGC developers on providing better
development tools for that or provide some good way to measure
compilation speed (SPEC tests do have compilation time graphs but they
are not too usefull as they are with checking enabled and SPECs are too
small to make changes visible in the noise). Or you can find some other
way to contribute to GCC.

We are are trying hard to make wide range of GCC users happy  and we
hope to find a way to make GCC both faster and producing better code,
but this is a lot of effort and a lot of things may get missed.

Honza