This is the mail archive of the
mailing list for the GCC project.
Re: Massive performance regression from switching to gcc 4.5
- From: Benjamin Smedberg <benjamin at smedbergs dot us>
- To: Andrew Pinski <pinskia at gmail dot com>
- Cc: Taras Glek <tglek at mozilla dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Thu, 24 Jun 2010 16:14:27 -0400
- Subject: Re: Massive performance regression from switching to gcc 4.5
- References: <4C23A90C.firstname.lastname@example.org> <AE37111E-D5B1-4BF2-8938-937D2A1940D9@gmail.com>
On 6/24/10 3:06 PM, Andrew Pinski wrote:
Most of the code is compiled with -fPIC -fno-rtti -fno-exceptions -Os
Stop right there. You are compiling at -Os, that is tuned for size and
not speed. So the question is did the size go down? Not the speed
decreased. Try at -O2 and report back. I doubt we are going to do a
tradeoff for speed at -Os at all.
For what it's worth, Mozilla-compiled-with-GCC has historically been faster
compiled -Os instead of -O2. This is because the vast majority of our code
is cold, and -O2 has produced substantially larger code, which causes our
hot code to be evicted from processor caches more often.
We will definitely try -O2 to see if the previous measurements are no longer
valid with GCC 4.5.
Looking through our codesize comparison logs, some of our methods are
thosands of bytes longer with GCC 4.5 than 4.3 (same -Os compiler flags):
In addition, it appears at first glance that GCC is either no longer
inlining at -Os, even when it would be a size advantage to do so, or is
making some very poor inlining choices.
e.g. +72 nsTArray<ObserverRef>::nsTArray(nsTArray<ObserverRef> const&)
We can turn some of these observations into bug reports if that would be
helpful, but if it would make more sense we could perhaps just tune the
inlining parameters directly to get the "real -Os" that we usually want.