Re: gcc compile-time performance

[Marc Espie <espie at quatramaran dot ens dot fr>]

In article <20020518011432.E006DF28EC@nile.gnat.com> you write:
>> I'd like to particularly point out the BSD folks, I totally agree with
>> their arguments.  When you have to bootstrap entire systems on old
>> hardware, using gcc-3.1 is a complete and utter joke.  That is not
>> funny and I vow to work on fixing this.  People like Mark are fixing
>> stupid things the java compiler does during a bootstrap.
>
>Old hardware can indeed be a problem. Certainly in our environment, no one
>would have programmers costing $1000/day stuck using old slow hardware. So
>I agree that makes a considerable difference.

gcc is supposed to help with free software, right ?
Well, free software doesn't follow normal economic guidelines.

People work with old architectures for the challenge, and because they
have fun with it. And some other people are very happy to be able to DO
something, like run Unix, on their 1980 amiga/atari/vax/m88k/whatever.

The big problem is that, once this stops being fun, people stop playing
with old hardware.

Over the past few years, the main thing that has been making this less fun
is... gcc.   Between the reduced support for old architectures (somewhat
unavoidable, and not your fault guys), the huge slowdown in recent gccs
is killing those architectures. Some OpenBSD developers, the ones who work
on m88k, vax, etc, even believe the switch to 2.95.3 was a mistake.

Of course, since the compiler upgrades not only slow it down, but also add
support to new language features, it gets more frustrating: because new
software will want the new features, so it gets more frustrating and less
fun for the guys playing with old architectures.

At some point, they just quit. We have this happen once or twice already.


I know where the big advice is coming: use different gcc versions for
various architectures... hum, except for the fact that it is a maintenance
nightmare, and that different gcc have different bugs all over the place,
imagine the fun with third party software, which will sometimes compile with
2.8, and sometimes require 3.0 or more.  What makes it more frustrating is
that some of these differences are gratuitous. (Plus, OpenBSD focuses on 
robustness...  it's hard to ensure robustness against compiler bugs in various
versions on various platforms).

Also, the size of some free software organizations does not allow this kind
of stunt.   I don't think the NetBSD team that handles the toolchain is THAT
large (there are probably a few guys who handle arch-specific stuff, and not
that many who handle gcc proper). I don't think the FreeBSD team is that large
either (though they have the easiest setup, since they don't support that
many architectures), and the OpenBSD team is rather small.

Officically supporting different compilers would stretch it OVER the limit.

So, what's going to happen ? when gcc 3.0 rolled out, I had some issues with
it, and gcc 3.0.x marginally solves them.  I was hoping that gcc 3.1 would
be improved (due to personal circumstances, I did not have enough time to
follow it as thoroughly as I ought to). And now, I do see it's even slower
than 2.95.3.  Well, there's a simple choice: if we switch to gcc 3.1, we
kill m68k, sparc, m88k, vax... (more or less). So we probably won't switch.

And now, I'm going to try to get flamed...
I think that the main problem comes from the simple fact that it is rather
unsexy to work on speed increases in gcc, compared to adding new-fangled
optimizations that gain 0.05% on a SPEC test, and which are not even finished
overall. I think that the guys who try their best to do speed increases in gcc
are somewhat hampered, because almost nobody else gives a XXXX about it, so
it takes forever to integrate their work.

I hope this can change.  I assume that now you all know how things stand 
in OpenBSD land.