public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: NightStrike <nightstrike@gmail.com>
To: Alexander Zaitsev <zamazan4ik@tut.by>
Cc: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Subject: Re: Document how to build PGO-optimized GCC version
Date: Wed, 28 Dec 2022 02:22:28 -0500	[thread overview]
Message-ID: <CAF1jjLuckviGBVu5WvZktzG8Txbv3n2snhP0RUSepH-EDhMP7A@mail.gmail.com> (raw)
In-Reply-To: <387a052a-60f2-3d03-38d4-dcff21aaaa03@tut.by>

[-- Attachment #1: Type: text/plain, Size: 1813 bytes --]

On Wed, Dec 28, 2022, 00:37 Alexander Zaitsev <zamazan4ik@tut.by> wrote:

> Hello.
>
> We are using GCC for our C++ projects. Our projects are huge, commit
> rate is quite huge, so our CI workers are always busy (so as any other
> CI workers, honestly). Since we want to increase build speed, one of the
> option is to optimize the compiler itself. Sounds like a good case for PGO.
>
> Clang has the infrastructure for building the Clang itself with PGO:
> https://llvm.org/docs/HowToBuildWithPGO.html . I have tried to find
> something like that for GCC but with no success.
>
> My proposal is:
>
>   * add support for building PGO-optimized GCC into the GCC build
>     infrastructure
>   * add documentation to the GCC site, how to build GCC with PGO
>     optimizations
>   * (if GCC community provides prebuilt gcc binaries) use PGO for the
>     prebuilt binaries. E.g. Clang and rustc already uses this approach.
>
> Any feedback is appreciated.
>
> Thanks in advance!
>
> --
> Best regards,
> Alexander Zaitsev
>

I would wager that you would get more bang for your buck out of 1) building
a more recent gcc yourself instead of using whatever comes packaged, and 2)
building with march=native for each processor type you run on. Not that PGO
won't help, of course it will since you are building the same software
repeatedly, but my personal experience doing the exact same thing is that I
saw a 50% performance improvement from just from that, and it's rather
trivial to do if your infrastructure is homogeneous (mine was a many node
compute cluster). The next biggest bottleneck for me was IO, because the
project this was for when compiling was very file intensive.

Anyway, just some alternative suggestions, since there's already a response
giving you what you asked for. Feel free to ignore me :)

>

      parent reply	other threads:[~2022-12-28  7:22 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-28  5:36 Alexander Zaitsev
2022-12-28  5:48 ` Andrew Pinski
2022-12-28  8:57   ` Martin Liška
2022-12-28  7:22 ` NightStrike [this message]

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=CAF1jjLuckviGBVu5WvZktzG8Txbv3n2snhP0RUSepH-EDhMP7A@mail.gmail.com \
    --to=nightstrike@gmail.com \
    --cc=gcc@gcc.gnu.org \
    --cc=zamazan4ik@tut.by \
    /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).