Skip to content

Usage of BOLT (the LLVM post-optimizer) #93626

Description

@deeprobin

In the .NET area, we have already made great strides in the PGO area.

The Rust compiler (rustc) has been optimized with BOLT since last week (see rust-lang/rust#94381).
BOLT originally comes from a Facebook Incubator project, which will then be adopted into LLVM at some point.

Apparently they talk about ~2% performance optimization when using that.

Here, of course, we can think about whether this makes much difference in JIT scenarios, since here it basically only optimizes the static parts (e.g. apphost, corerun, ...).

However, I see potential here especially in the NativeAOT area.

The only thing required would be PGO data like perf outputs.

The difference to other optimizers is that this is a post optimizer, so this tries to optimize the binaries.
One limitation I could find so far is that it only supports ELF binaries (at least what I could find out).


Would be very interested if you guys see any thoughts, challenges or obstacles here to optimize the .NET binaries with this.

If nothing stands in the way of this I would sit down to a PoC on how we could use this in runtime.

/type:feature
/area:PGO

Activity

  1. ghost added
    needs-area-labelAn area label is needed to ensure this gets routed to the appropriate area owners
    on Oct 17, 2023
  2. ghost added
    untriagedNew issue has not been triaged by the area owner
    on Oct 17, 2023
  3. Perksey commented on Oct 17, 2023

    @Perksey
    Member

    This does raise an interesting point about .NET using PGO to optimise itself. e.g. consider we could collect static PGO data of .NET compiling itself and bundle that in with R2R images of the various .NET binaries, and if we go the BOLT route as well we can instrument corerun as its compiling itself, and have a high-quality set of PGO data we're ready to run with. It looks like Rust just uses a few common crates to optimise itself.

  4. added
    area-CodeGen-coreclrCLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
    on Oct 17, 2023
  5. removed
    needs-area-labelAn area label is needed to ensure this gets routed to the appropriate area owners
    on Oct 18, 2023
  6. JulieLeeMSFT commented on Oct 18, 2023

    @JulieLeeMSFT
    Member

    We internally discussed about this recently. CC @kunalspathak, @EgorBo, @AndyAyersMS.

  7. JulieLeeMSFT commented on Oct 18, 2023

    @JulieLeeMSFT
    Member

    In .NET 9, we are starting with #92915. Opportunistically, we might look into utilizing BOLT.

  8. removed
    untriagedNew issue has not been triaged by the area owner
    on Oct 18, 2023
  9. added this to the Future milestone on Oct 18, 2023
  10. EgorBo commented on Oct 18, 2023

    @EgorBo
    Member

    BOLT might makes sense to try for e.g. GC and VM native code but it seems unlikely it will result into anything meanigful (even -march=native and -O3 has no visible impact compared with our defaults).

    For NativeAOT/generated managed code it's very unlikely to be usable at all due to GC info, etc so we're sceptical about it, I am sure we have simpler things to do to get 2% improvement rather than hooking a heavy/slow lib into CI 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area-CodeGen-coreclrCLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions