Last Comment Bug 554364 - use -fomit-frame-pointer on Linux
: use -fomit-frame-pointer on Linux
Status: RESOLVED FIXED
: perf
Product: Toolkit
Classification: Components
Component: Breakpad Integration (show other bugs)
: Trunk
: x86 Linux
: P1 normal (vote)
: mozilla1.9.3a4
Assigned To: Ted Mielczarek [:ted.mielczarek]
:
Mentors:
Depends on: 464750 554019 554024
Blocks:
  Show dependency treegraph
 
Reported: 2010-03-23 10:19 PDT by Jim Blandy :jimb
Modified: 2010-05-01 07:37 PDT (History)
21 users (show)
bugzillamozillaorg_serge_20140323: in‑testsuite-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
add -fomit-frame-pointer to MOZ_OPTIMIZE_FLAGS [Checkin: Comment 8] (1.74 KB, patch)
2010-03-26 11:08 PDT, Ted Mielczarek [:ted.mielczarek]
jimb: review+
Details | Diff | Review
(Bv1-CC) Copy it to comm-central [Checkin: Comment 12] (1.32 KB, patch)
2010-03-27 11:02 PDT, Serge Gautherie (:sgautherie)
bugspam.Callek: review+
Details | Diff | Review

Description Jim Blandy :jimb 2010-03-23 10:19:28 PDT
+++ 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.
Comment 1 Justin Dolske [:Dolske] 2010-03-24 14:34:06 PDT
FWIW, the last compiler option tuning I remember being done for Linux was in bug 409803...
Comment 2 dwitte@gmail.com 2010-03-24 15:07:24 PDT
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. :)
Comment 3 Ted Mielczarek [:ted.mielczarek] 2010-03-25 03:57:13 PDT
Note that we're using GCC 4.3.3 nowadays, to start.
Comment 4 Ted Mielczarek [:ted.mielczarek] 2010-03-26 11:07:33 PDT
Scoping this down slightly, someone else can fiddle with the optimization flags further if they want.
Comment 5 Ted Mielczarek [:ted.mielczarek] 2010-03-26 11:08:16 PDT
Created attachment 435223 [details] [diff] [review]
add -fomit-frame-pointer to MOZ_OPTIMIZE_FLAGS
[Checkin: Comment 8]
Comment 6 Jim Blandy :jimb 2010-03-26 11:20:45 PDT
Okay. Let's give it a spin.
Comment 7 Jim Blandy :jimb 2010-03-26 11:22:01 PDT
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
Comment 8 Ted Mielczarek [:ted.mielczarek] 2010-03-26 11:28:13 PDT
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.
Comment 9 Serge Gautherie (:sgautherie) 2010-03-27 11:02:08 PDT
Created attachment 435399 [details] [diff] [review]
(Bv1-CC) Copy it to comm-central
[Checkin: Comment 12]
Comment 10 Serge Gautherie (:sgautherie) 2010-03-27 11:04:24 PDT
(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 11 Justin Wood (:Callek) 2010-03-27 21:50:27 PDT
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]
Comment 12 Serge Gautherie (:sgautherie) 2010-03-28 08:47:36 PDT
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
Comment 13 Gábor Stefanik 2010-04-30 20:39:03 PDT
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?
Comment 14 Ted Mielczarek [:ted.mielczarek] 2010-05-01 07:37:50 PDT
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

Note You need to log in before you can comment on or make changes to this bug.