This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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).

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]