Closed Bug 554364 Opened 10 years ago Closed 10 years ago

use -fomit-frame-pointer on Linux

Categories

(Toolkit :: Crash Reporting, defect, P1)

x86
Linux
defect

Tracking

()

RESOLVED FIXED
mozilla1.9.3a4

People

(Reporter: jimb, Assigned: ted)

References

Details

(Keywords: perf)

Attachments

(2 files)

+++ This bug was initially created as a clone of Bug #492688 +++

We get a 5.5% (50ms) speedup with gcc on MacOSX when using -O3 and -fomit-frame-pointer instead of -Os. Peak speedup is 16% for md5. Everything seems to get faster. spectral-norm is probably a measurement outlier.

We should do this on Linux as well.
No longer depends on: 492688, 517832
FWIW, the last compiler option tuning I remember being done for Linux was in bug 409803...
Yeah, linux is different, in weird and wonderful ways, and needs to be tested separately. But hopefully gcc is saner than before, and the gains translate as hoped. :)
Note that we're using GCC 4.3.3 nowadays, to start.
Scoping this down slightly, someone else can fiddle with the optimization flags further if they want.
Summary: Use -O3 -fomit-frame-pointer instead of -Os on Linux → use -fomit-frame-pointer on Linux
Assignee: nobody → ted.mielczarek
Status: NEW → ASSIGNED
Attachment #435223 - Flags: review?(jim)
Attachment #435223 - Flags: review?(jim) → review+
Okay. Let's give it a spin.
For what it's worth, here are some directories that set MODULE_OPTIMIZE_FLAGS that could enable -fomit-frame-pointer:

./db/sqlite3/src/Makefile.in
./gfx/cairo/cairo/src/Makefile.in
./gfx/cairo/libpixman/src/Makefile.in
./memory/jemalloc/Makefile.in
./netwerk/protocol/ftp/src/Makefile.in
./xpcom/io/Makefile.in
Pushed to m-c:
http://hg.mozilla.org/mozilla-central/rev/6c003a9165b9

Yeah, we can twiddle those in a followup if we want to. Might be a little more perf to be gained. The original bug was more concerned with JS perf, which we've covered here.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a4
Flags: in-testsuite-
Version: unspecified → Trunk
(In reply to comment #7)
> For what it's worth, here are some directories that set MODULE_OPTIMIZE_FLAGS
> that could enable -fomit-frame-pointer:

Fwiw,
http://mxr.mozilla.org/mozilla-central/search?string=MODULE_OPTIMIZE_FLAGS&case=on
Comment on attachment 435399 [details] [diff] [review]
(Bv1-CC) Copy it to comm-central
[Checkin: Comment 12]

fyi, c-c has none of the MOZ_OPTIMIZE_FLAGS override problems [except in the backport of sqlite in our top level; but I'll leave that to Mail team to care about]
Attachment #435399 - Flags: review?(bugspam.Callek) → review+
Comment on attachment 435399 [details] [diff] [review]
(Bv1-CC) Copy it to comm-central
[Checkin: Comment 12]


http://hg.mozilla.org/comm-central/rev/cbe96b862e08
Attachment #435399 - Attachment description: (Bv1-CC) Copy it to comm-central → (Bv1-CC) Copy it to comm-central [Checkin: Comment 12]
Attachment #435223 - Attachment description: add -fomit-frame-pointer to MOZ_OPTIMIZE_FLAGS → add -fomit-frame-pointer to MOZ_OPTIMIZE_FLAGS [Checkin: Comment 8]
Keywords: perf
Out of curiosity, why are we using -Os (optimize for code size), rather than e.g. -O2 (optimize for execution speed)? Does -Os actually run faster than the real speed optimization, or is code size still more important than speed on today's high-bandwidth connections?
Previous tests showed that using -Os for most of our codebase actually produced code that ran faster. It's possible that it has to do with cache sizes, etc. We are compiling our JavaScript library at -O3, since the optimizations are a definite win there:
http://mxr.mozilla.org/mozilla-central/source/js/src/Makefile.in#91
You need to log in before you can comment on or make changes to this bug.