This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gcc and compiling speed
- From: Zack Weinberg <zack at codesourcery dot com>
- To: Theo de Raadt <deraadt at cvs dot openbsd dot org>
- Cc: Andrew Pinski <pinskia at physics dot uc dot edu>, 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 23:27:17 -0800
- Subject: Re: gcc and compiling speed
- References: <200403010349.i213nxpD008197@cvs.openbsd.org><8765dpqkpq.fsf@egil.codesourcery.com><20040301071403.GA8953@tetto.gentiane.org>
Marc Espie <espie@nerim.net> writes:
>> What you don't realize, perhaps, is just how data-driven gcc (any
>> version) is. I could spend weeks tuning gcc to work well on mozilla
>> and it could make no. difference. whatsoever. to how long it takes to
>> compile OpenBSD core.
Thank you.
> I'm just busy with various things, including an upcoming OpenBSD release,
> and a move between apartments, but I'll provide this preprocessed source
> as soon as it gets on the top list of my things to do.
>
> On the other hand, what you're saying is plain bullshit, Zack. The slowdown
> of gcc3 vs. gcc2 is NOT dependent on the set of source files.
You misunderstand. I do not deny that gcc 3.3 is slower than gcc 2.95
for almost all C input (*please* be specific about minor version
numbers - 3.0, 3.[12], 3.3, 3.4, and mainline are all very different
beasts). I have observed the slowdown myself, in fact.
What I said was that speeding up GCC for one set of source files is
unlikely to speed it up for another. This is *also* true. And this
is why we keep asking you for your test cases.
(If we get *enough* test cases, we can cover all the code paths and
speed the compiler up in general, but we aren't there yet.)
zw