From: Jan Hubicka <hubicka@ucw.cz>
To: Qing Zhao <qing.zhao@oracle.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: Set inline-unit-growth to 40
Date: Tue, 15 Jan 2019 15:14:00 -0000 [thread overview]
Message-ID: <20190115151442.ge5brvlz5myq3fx7@kam.mff.cuni.cz> (raw)
In-Reply-To: <BF653329-D45E-4EC0-88AD-AC983EB941D0@oracle.com>
> Hi, Honza,
>
> in addition to the code size problems, there are several runtime regression for the SPEC: (If I read the table correctly, if not, let me know)
>
> SPEC/SPEC2006/INT/483.xalancbmk <https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=183.290.0> 146.131 4.89%
This test seems to be just a noise, if you look on the mainline plots
there is no noticeable regression and you can see differences +- 4% in
last 10 runs.
>
> SPEC/SPEC2006/FP/436.cactusADM <https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=171.100.0> 130.967 8.07%
>
> SPEC/SPEC2017/INT/520.omnetpp_r <https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=172.357.0> 395.582 4.98%
Here you can see in the graph both boxes to be yellow which means that
binary did not changed nor the size changed. It is just measurement error it seems.
>
> SPEC/SPEC2006/FP/435.gromacs <https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=177.90.0> 182.555 11.73%
I plan to check on gromacs
This is LTO+PGO which will be rerun only in day or two so I will see if
the same regression stays on mainline.
>
> SPEC/SPEC2017/INT/541.leela_r <https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=174.397.0> 452.333 4.17%
This was already taken by daily testers and regression does not
reproduce, so it seems to be noise too.
Honza
>
> do we have plan to study and fix these run-time regression?
>
> thanks.
>
> Qing
>
> > On Jan 12, 2019, at 12:32 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
> >
> > Hello,
> > this patch sets inline-unit-growth to 40. The performance changes are
> > - Firefox, LTO
> > https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=f7bd026e1a931b9a284d1c85c2577a72dd592820&newProject=try&newRevision=74889968abcc688b8d161863566ed273c0401ee4&framework=1&filter=opt&showOnlyComparable=1&showOnlyImportant=1
> > After fixes to inlining priorities this makes difference without
> > profile feedback only.
> >
> > Code size growth is about 9.15% with LTO and 3.95 with LTO and profile
> > feedback.
> > - Firefox noLTO
> > https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=c902b72340a3dca3114f58578c1c8f3e6a1cd89c&newProject=try&newRevision=4974da6f92c144a9c09765b56a564a640069ddb9&framework=1&showOnlyComparable=1&showOnlyImportant=1
> > With about 7% code size growth
> > - SPEC
> > https://lnt.opensuse.org/db_default/v4/CPP/latest_runs_report?num_runs=10&min_percentage_change=0.02&revisions=46e2bd1143b5c60af814916d7673879b34ceb3f6%2Cc0d79cfe9c4ec30823480f2f9b256600e8e3899f
> > - C++ benchmarks
> > https://lnt.opensuse.org/db_default/v4/SPEC/latest_runs_report?num_runs=10&all_changes=on&min_percentage_change=0.02&revisions=46e2bd1143b5c60af814916d7673879b34ceb3f6%2Cc0d79cfe9c4ec30823480f2f9b256600e8e3899f
> >
> > I am not entirely happy about the code-size/performance tradeoffs but it
> > is concerned only for programs built with -O3 or having too many inline
> > keywords. I have looked into inlining decisions for Firefox, HHVM and
> > Clang and inliner gets out of growt bounds way too early and some of
> > more performance aware projects already sets the limit up.
> >
> > I will tune other metrics down to handle some of the code size problems.
> >
> > Honza
> >
> > Index: ChangeLog
> > ===================================================================
> > --- ChangeLog (revision 267882)
> > +++ ChangeLog (working copy)
> > @@ -1,3 +1,7 @@
> > +2019-01-05 Jan Hubicka <hubicka@ucw.cz>
> > +
> > + * params.def (inline-unit-growth): Set to 40.
> > +
> > 2019-01-12 Jakub Jelinek <jakub@redhat.com>
> >
> > * tree-ssa-loop-ivopts.c (find_inv_vars): Fix a comment typo.
> > Index: params.def
> > ===================================================================
> > --- params.def (revision 267882)
> > +++ params.def (working copy)
> > @@ -227,7 +227,7 @@ DEFPARAM(PARAM_LARGE_UNIT_INSNS,
> > DEFPARAM(PARAM_INLINE_UNIT_GROWTH,
> > "inline-unit-growth",
> > "How much can given compilation unit grow because of the inlining (in percent).",
> > - 20, 0, 0)
> > + 40, 0, 0)
> > DEFPARAM(PARAM_IPCP_UNIT_GROWTH,
> > "ipcp-unit-growth",
> > "How much can given compilation unit grow because of the interprocedural constant propagation (in percent).",
>
next prev parent reply other threads:[~2019-01-15 15:14 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-12 18:32 Jan Hubicka
2019-01-14 16:28 ` Christophe Lyon
2019-01-14 16:40 ` Jan Hubicka
2019-01-17 13:22 ` Christophe Lyon
2019-01-14 16:53 ` Qing Zhao
2019-01-15 15:14 ` Jan Hubicka [this message]
2019-01-15 16:18 ` Qing Zhao
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=20190115151442.ge5brvlz5myq3fx7@kam.mff.cuni.cz \
--to=hubicka@ucw.cz \
--cc=gcc-patches@gcc.gnu.org \
--cc=qing.zhao@oracle.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).