public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
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

  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).