This is the mail archive of the
mailing list for the GCC project.
gcc 3.1 is still very slow, compared to 2.95.3
- From: Marc Espie <espie at nerim dot net>
- To: gcc at gcc dot gnu dot org
- Date: Fri, 17 May 2002 14:42:58 +0200
- Subject: gcc 3.1 is still very slow, compared to 2.95.3
- Reply-to: espie at nerim dot net
Compiling the OpenBSD kernel:
gcc 2.95.3 yields:
make 229.16s user 20.34s system 89% cpu 4:38.64 total
gcc 3.1 yields:
make CC=egcc 398.28s user 22.55s system 91% cpu 7:40.39 total
This is not quite twice as slow, but very close.
I would have expected things to somehow come back to normal after
the somewhat disastrous 3.0.x results.
It's not even clear the new compiler does a much better job. After all,
gcc itself is slower, isn't it ?
Same set of optimizations, mostly -O2.
This is a major show-stopper for us. Basically, it means that we can't
use gcc 3.1 without effectively killing, oh, about half the arches we
are supposed to support: m68k, vax, m88k, sparc, at least.
For instance, this means that a 68040 machine will jump from 3 days to
5 days for a complete make build... A sun3 will go from ten days to
And that's for make build. On a machine which does a make build in 1 hour
takes... 18 hours to build the rest of the packages in our system.
Scale that to m68k and friends.
Okay, now, what passes is gcc 3.1 running that slow it down that much ?
What would be the equivalent set of options to gcc's 2.95.3 -O2, so that
I can see whether we can get down to more reasonable numbers ?