This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gcc and compiling speed
- From: Steven Bosscher <s dot bosscher at student dot tudelft dot nl>
- To: Theo de Raadt <deraadt at cvs dot openbsd dot org>,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: Mon, 1 Mar 2004 09:07:49 +0100
- Subject: Re: gcc and compiling speed
- References: <200403010259.i212xS6m023756@cvs.openbsd.org>
On Monday 01 March 2004 03:59, Theo de Raadt wrote:
> > 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 suppose you're right about most gcc3 releases, yes they're slower
than 2.95.3. This is a known issue and for gcc 3.4 we're trying harder
again to make it faster than previous gcc3 releases. All I have seen
from OpenBSD to help out with this is occasional bashing of gcc, but
no test cases or performance tracking on a regular basis.
> 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?
What about better diagnostics, correctness, reliability, other things
that have improved significantly since gcc2, in areas that help you,
as a programmer? You conveniently ignore them.
(Hint: turning off diagnostics will also make your compiler faster.)
> One that does not become 2x slower in 3 years, for absolutely no
> percievable benefit in performance (and the output binaries got
> larger too).
There is performance checking using SPEC benchmarks. There are
numbers (http://www.suse.de/~aj/SPEC/CINT/sandbox-b/SPECint_big.png)
that suggest gcc _does_ produce better code compared to >2 years
ago. There also are numbers for the size of the binaries produced
for SPEC (http://www.suse.de/~aj/SPEC/CINT/sandbox-b/Total-size_big.png).
Finally, there is a special-purpose code-size benchmark called CSiBE
(http://sed.inf.u-szeged.hu/csibe/) that is run on a daily basis for
a number of targets.
The people maintaining these testers kick us when we have regressions.
But as you can see, the trends have been good over the past few years.
So for all we know, things are not as dramatic as OpenBSD people like
to put it. And where things are worse than before, we need your help
to find out why and to do something about it.
Gr.
Steven
---
The USA, land of the free, hope of the brave. Only a bit too scared now.
http://www.cbc.ca/news/background/arar/