public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jan Hubicka <hubicka@ucw.cz>
To: "Martin Liška" <mliska@suse.cz>
Cc: Qing Zhao <qing.zhao@oracle.com>,
	gcc Patches <gcc-patches@gcc.gnu.org>,
	Martin Jambor <mjambor@suse.cz>
Subject: Re: Question on patch -fprofile-partial-training
Date: Tue, 9 May 2023 12:22:43 +0200	[thread overview]
Message-ID: <ZFoe88Ad4L2Tp6UJ@kam.mff.cuni.cz> (raw)
In-Reply-To: <30e4827a-1a4d-1a26-6158-5e7c967e5268@suse.cz>

> > > > 
> > > >  From my understanding, -fprofile-partial-training is one important option for PGO performance.
> > > 
> > > I don't think so, speed benefit would be rather small I guess.
> > I saw some articles online to introduce this option for gcc10,
> > https://documentation.suse.com/sbp/all/html/SBP-GCC-10/index.html#sec-gcc10-pgo
> 
> Hi.
> 
> Ah, I see.
> 
> > And also based on my previous experience in Studio compiler, I guess that this one might have
> > Some good performance impact on PGO.  Is there any old performance data on this option? (I cannot find online)
> 
> Maybe Honza can chime in here? Or Martin who is the author of the white paper.

Main motivation for this was profiling programs that contain specific
code paths for different CPUs (such as graphics library in Firefox or Linux
kernel). In the situation training machine differs from the machine
program is run later, we end up optimizing for size all code paths
except ones taken by the specific CPU.  This patch essentially tells gcc
to consider every non-trained function as built without profile
feedback.

For Firefox it had important impact on graphics rendering tests back
then since the building machined had AVX while the benchmarking did not.
Some benchmarks improved several times which is not a surprise if you
consider tight graphics rendering loop optimized for size versus
vectorized one.  The patch has bad effect on code size which in turn
impacts performance too, so I think it makes sense to use
-fprofile-partial-training with bit of care (i.e. only one code where
such scenarios are likely).

As for backporting, I do not have checkout of GCC 8 right now. It
depends on profile infrastructure that was added in 2017 (so stage1 of
GCC 8), so the patch may backport quite easilly.  I am not 100% sure
what shape the infrastrucure was in the first version, but I am quite
convinced it had the necessary bits - it was able to make the difference
between 0 profile count and missing profile feedback.

Honza
> 
> Martin
> 
> > 
> > thanks.
> > 
> > Qing
> > 
> > > 
> > > > I’d like
> > > > to see any big technique difficult to prevent it from being back ported to GCC8.
> > > 
> > > There might be of course some patch dependencies and I don't see a point why should we waste
> > > time with that.
> > > 
> > > Cheers,
> > > Martin
> > > 
> > > > 
> > > > Thanks.
> > > > 
> > > > Qing
> > > > 
> > > > > 
> > > > > Martin
> > > > > 
> > > > > > 
> > > > > > Can this patch be back ported to GCC8 easily? I am wondering any significant
> > > > > > Change between GCC8 and GCC10 that might make the backporting very hard>
> > > > > > Thanks a lot for your help.
> > > > > > 
> > > > > > Qing
> > 
> 

  reply	other threads:[~2023-05-09 10:22 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-03 19:10 Qing Zhao
2023-05-04  8:30 ` Martin Liška
2023-05-04 12:54   ` Qing Zhao
2023-05-04 13:05     ` Martin Liška
2023-05-04 13:37       ` Qing Zhao
2023-05-09 10:06         ` Martin Liška
2023-05-09 10:22           ` Jan Hubicka [this message]
2023-05-09 20:11             ` Qing Zhao
2023-05-10 13:15               ` Jan Hubicka
2023-05-11 16:08                 ` Qing Zhao
2023-05-15 18:14                   ` 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=ZFoe88Ad4L2Tp6UJ@kam.mff.cuni.cz \
    --to=hubicka@ucw.cz \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=mjambor@suse.cz \
    --cc=mliska@suse.cz \
    --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).