From: Jan Hubicka <hubicka@ucw.cz>
To: "Martin Liška" <mliska@suse.cz>
Cc: GCC Development <gcc@gcc.gnu.org>,
Richard Biener <richard.guenther@gmail.com>,
Michael Matz <matz@suse.de>,
tom@mozilla.com
Subject: Re: How big (and fast) is going to be GCC 8?
Date: Mon, 12 Mar 2018 15:05:00 -0000 [thread overview]
Message-ID: <20180312150456.GA81162@kam.mff.cuni.cz> (raw)
In-Reply-To: <5ec1f1c1-e0f6-5681-b6c6-cf8b076bc02a@suse.cz>
Hello,
I have also re-done most of my firefox testing similar to ones I published at
http://hubicka.blogspot.cz/2014/04/linktime-optimization-in-gcc-2-firefox.html
(thanks to Martin Liska who got LTO builds to work again)
I am attaching statistics on binary sizes. Interesting is that for firefox LTO is quite
good size optimization (16% on text) and similarly FDO reduces text size and combines well
with LTO, which is bit different from Martin's gcc stats. I have looked into this very
briefly and one isse seems to be with the way we determine hot/cold threshold.
binary size text relocations data EH rest
gcc6 -O3 90448658 12887358 13720073 13035704 257839
gcc6 -O3 -flto 75810786 12145211 12390185 8422776 240002
gcc6 -O3 + FDO 67087824 13008294 13655305 13719944 259585
gcc6 -O3 -flto + FDO 60206898 12169803 12334113 9083088 240050
gcc7 -O3 93233440 12928831 13780313 13578224 257408
gcc7 -O3 -flto 76764274 12128031 12405369 8420448 240662
gcc7 -O3 + FDO 67500688 12994279 13650185 13661760 263400
gcc7 -O3 -flto + FDO 59776994 12151360 12325217 8971344 239501
gcc8 -O2 80311120 12939568 13763033 12948752 258711
gcc8 -O2 -flto 69156752 12109236 12475801 8501152 240163
gcc8 -O3 89913648 12924468 13790393 13374328 256867
gcc8 -O3 -flto 75971122 12138528 12426649 8593024 239861
gcc8 -O3 + FDO 67047632 12996890 13707017 13146232 263413
gcc8 -O3 -flto + FDO 58951410 12146008 12377161 8634152 241765
I also did some builds with clang. Observation is that clang's -O3 binary is
smaller than ours, while our LTO/FDO builds are smaller than clang's (LTO+FDO
build quite substantially).
Our EH is bigger than clang's which is probably something to look into. One problem I am
aware of is that our nothrow pass is not type sensitive and thus won't figure out if
program throws an exception of specific type and catches it later.
clang6 -O3 84754848 13032018 13597433 10791528 371429
clang6 -O3 -flto 90757024 12273574 12258521 6841424 350585
clang6 -O3 -flto=thin 92940576 12376724 12479233 7974856 353171
clang6 -O3 + FDO 81776880 13136428 13574489 11501344 385123
clang6 -O3 -flto=thin+FDO 88374432 12405075 12434297 9574416 356508
clang6 -O3 -flto + FDO 90637168 12288433 12244265 9023304 349078
I also did some benchmarking and found at least an issue with -flto -O3 hitting
--param inline-unit-growth bit too early so we do not get much benefits (while
clang does but it also does not reduce binary size). -O3 -flto + FDO or -O2
-flto seems to work well. Will summarize the results later.
Firefox developer Tom Ritter has tested LTO with FDO and without here (it is
rather nice interface - I like that one can click to the graph and see the
results in context of other tests done recently). This is done with gcc6.
Tracking bug:
https://bugzilla.mozilla.org/show_bug.cgi?format=default&id=521435
non-FDO build:
https://treeherder.mozilla.org/perf.html#/compare?originalProject=mozilla-central&newProject=try&newRevision=12ce14a5bcac9975b41a1f901bfc3a8dcb2d791b&framework=1&showOnlyImportant=1&selectedTimeRange=172800
FDO build:
https://treeherder.mozilla.org/perf.html#/compare?originalProject=mozilla-central&newProject=try&newRevision=7e5bd52e36fcc1703ced01fe87e831a716677295&framework=1&showOnlyImportant=1&selectedTimeRange=172800
Honza
next prev parent reply other threads:[~2018-03-12 15:05 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5ec1f1c1-e0f6-5681-b6c6-cf8b076bc02a@suse.cz>
2018-03-06 10:32 ` Richard Biener
2018-03-06 14:59 ` Jan Hubicka
2018-03-12 15:05 ` Jan Hubicka [this message]
2018-03-06 10:14 Martin Liška
2018-03-06 15:13 ` David Malcolm
2018-03-06 16:18 ` Martin Liška
2018-03-06 18:35 ` Martin Liška
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180312150456.GA81162@kam.mff.cuni.cz \
--to=hubicka@ucw.cz \
--cc=gcc@gcc.gnu.org \
--cc=matz@suse.de \
--cc=mliska@suse.cz \
--cc=richard.guenther@gmail.com \
--cc=tom@mozilla.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).