This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gcc and compiling speed
- From: Theo de Raadt <deraadt at cvs dot openbsd dot org>
- To: Andrew Pinski <pinskia at physics dot uc dot edu>
- Cc: tech at openbsd dot org, Marc Espie <espie at quatramaran dot ens dot fr>, "gcc at gcc dot gnu dot org List" <gcc at gcc dot gnu dot org>
- Date: Sun, 29 Feb 2004 19:59:28 -0700
- Subject: Re: gcc and compiling speed
> Marc,
> Now I know you have been asked before every time you bring up on the
> GCC's mailing list about a set of preprocessed source for openbsd so
> that the speed of GCC will improve.
How will this improve the speed of gcc?
Are pre-processed headers the way that gcc3 is going to recover
the speed that it has lost?
> It seems like you are ignoring
> them and still complain about the compile time speed regressions in
> GCC.
And I well think that he should. I've been watching this from the
side lines. I am just flabbergasted at how we keep being told that
gcc will become faster, yet every release, it is in fact slower. Can
someone inside the compiler group please... PLEASE... make it a
mandate that noone will ever again make such a promise?
Because there has *never* been a gcc that compiled code faster than
the previous release did.
> If you (or some from the openbsd project) submit a bug with
> numbers and a way to reproduce it with say the openbsd's kernel
> sources, we will no longer disagree with you and fix the problem
> in GCC.
The problem is when a ultrasparc cpu takes 40% more time to build the
source tree. For no perceivable benefit; really.
I understand that there is a goal to make gcc produce better output
code.
But we are programmers. We spend our lives compiling code. When can
we get a compiler that is tuned for us?
One that does not become 2x slower in 3 years, for absolutely no
percievable benefit in performance (and the output binaries got
larger too).