Tracking issue for speeding up rustc via its build configuration

[nnethercote]

There are several ways to speed up rustc by changing its build configuration, without changing its code: use a single codegen unit (CGU), profile-guided optimization (PGO), link-time optimization (LTO), post-link optimization (via BOLT), and using a better allocator (e.g. jemalloc or mimalloc).

This is a tracking issue for doing these for the most popular Tier 1 platforms: Linux64 (x86_64-unknown-linux-gnu), Win64 (x86_64-pc-windows-msvc), and Mac (x86_64-apple-darwin).

Items marked with [2022] are on the Compiler performance roadmap for 2022.

Single CGU

Benefits: rustc is faster, uses less memory, has a smaller binary.
Costs: rustc takes longer to build.

• Linux64: Build rustc with a single CGU on x64 Linux #115554, merged 2023-10-01.
• Win64: Build rustc with 1CGU on x86_64-pc-windows-msvc #112267, merged 2024-03-12.
• Mac: Build rustc with 1CGU on x86_64-apple-darwin #112268, merged 2024-03-12.

PGO

Benefits: rustc is faster.
Costs: rustc takes longer to build.

• Linux64: Utilize PGO for rustc linux dist builds #80262, merged 2020-12-23.
• Win64 [2022]: Utilize PGO for windows x64 rustc dist builds #96978, merged 2022-07-12.
• Mac [2022]:
  • Problems with symbols not being matched correctly in PGO profiles.

Other PGO attempts:

• Call-site aware PGO for LLVM: Use CS PGO for LLVM #111806, no speed-up measured, seems like its benefits are superseded by BOLT.
• PGO for libstd: Apply PGO to libstd on CI #97038, no speed-up measured.

LTO

Benefits: rustc is faster.
Costs: rustc takes longer to build.

• Linux64:
  • rustc front-end: Enable LTO for rustc_driver.so #101403, merged 2022-10-24.
  • LLVM: done some time ago.
• Win64:
  • rustc front-end: Enable ThinLTO for rustc on x64 msvc #103591, merged 2022-12-11. Caused a miscompilation and was reverted on 2023-03-14.
  • LLVM [2022]: currently statically linked, which prevents LTO, but this could be changed
• Mac:
  • rustc front-end: Enable ThinLTO for rustc on x86_64-apple-darwin #103647 and Re-enable ThinLTO for rustc on x86_64-apple-darwin #105845, merged 2022-12-19.
  • LLVM [2022]

This is all thin LTO, which gets most of the benefits of fat LTO with a much lower link-time cost.

Other LTO attempts:

• LTO for rustdoc: [perftest] Use LTO for compiling rustdoc #102885, no speed-up measured.
• Fat LTO: Use fat LTO for compiling rustc #103453, no speed-up measured, large CI build cost.

BOLT

Benefits: rustc is faster.
Costs: rustc takes longer to build.

• Linux64:
  • rustc front-end: Optimize librustc_driver.so with BOLT  #116352, merged 2023-10-14.
  • LLVM: Use BOLT in CI to optimize LLVM #94381, merged 2022-10-10.
• Win64: N/A
• Mac: N/A

Bolt only works on ELF binaries, and thus is Linux-only.

Instruction set

Benefits: rustc is faster?
Costs: rustc won't run on old CPUs.

• x86_64: Update to v2/v3/APX sometime in the future. So far, the perf. wins haven't been convincing enough to upgrade, because it will reduce compatibility for older CPUs. Some perf. results can be found here.

Linker

Benefits: rustc (linking) is faster.
Costs: hard to get working.

• lld: Using lld by default would make linking times of crates much faster. Some perf. results can be found here.

Better allocator

Benefits: rustc (linking) is faster.
Costs: rustc uses more memory?

• Linux64: jemalloc, done some time ago.
• Win64 [2022]
• Mac: jemalloc, done some time ago.

Note: #92249 and #92317 tried using two different versions of mimalloc (one 1.7-based, one 2.0-based) instead of jemalloc, but the speed/memory tradeoffs in both cases were deemed inferior (the max-rss regressions expected to be fixed in the 2.x series still exist as of 2.0.6, see #103944).

Note: we use a better allocator by simply overriding malloc/free, rather than using #[global_allocator]. See this Zulip thread for some discussion about the sub-optimality of this.

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

[the8472]

Another thing to try that was brought up on zulip is aligning the text segment to 2MB so it can be loaded in a way that transparent huge pages kick in, but I'm not 100% sure if this even works yet, last time I checked large page support in the page cache was still a WIP and I haven't seen it in release notes.

[lqd]

An update for windows:

• I'm trying ThinLTO for rustc_driver.dll in Enable ThinLTO for rustc on x64 msvc #103591 as local results looked interesting enough (lower than what we saw on x86_64-unknown-linux-gnu but still quite good).
• I don't think we actually can ThinLTO LLVM separately on MSVC easily today: that is done by linking to LLVM as a shared library, which is not supported on x86_64-pc-windows-msvc. It's likely possible to do in the future, but is more involved than a build config tweak.

[nnethercote]

Another thing to try that was brought up on zulip is aligning the text segment to 2MB so it can be loaded in a way that transparent huge pages kick in

Given that it's not even clear that this works, let's leave it off this issue for now.

[the8472]

It looks like file-backed huge pages are supported now. https://www.kernel.org/doc/html/latest/filesystems/proc.html#meminfo

FileHugePages
Memory used for filesystem data (page cache) allocated with huge pages
FilePmdMapped
Page cache mapped into userspace with huge pages

I think it was introduced with this one torvalds/linux@793917d so it needs at least 5.18

It also depends on filesystem support.

[tschuett]

I read and actually checked that rustc links dynamically against rustc_driver. The same article said we dlopen codegen backends. Isn't there a way for the common case, a static binary: rustc + rustc_driver + LLVM?

[Kobzol]

We could do that in theory, but I'm not sure if it would be that useful. Static linking has some benefits, but mostly only for tiny crates, the diminishing returns start to kick in early. rustc is basically a "one-liner" that calls into the entrypoint of rustc_driver, and that is now LTO-optimized.

[tschuett]

I would enable LTO over the full binary. Startup time may also be better.

[Kobzol]

Well, the "full binary" is one function call into rustc_driver :) But it's true that I haven't tried benchmarking static linking on top of the current LTO optimized librustc_driver. I'll try it, to see if static linking + LTO could provide substantial benefits.

Shipping a statically linked rustc would probably only be possible on some OSes (Linux), and it would increase the size of the distributed artifacts by a nontrivial amount.

[tschuett]

My LLVM folder is full of large statically linked LTO'd binaries (OSX).

Could you also statically link in the LLVM backend?

[Kobzol]

In theory, yes. In practice, I'm not sure if our current build system supports it (will check).

[tschuett]

No worries.

-rwxr-xr-x 1 xxx staff 129M Jul 28 18:44 clang-15

It only links against system libraries and no LLVM libraries.

[Elabajaba]

I'm not sure if it helps, but on Windows LLVM can be built with a different allocator using the -DLLVM_INTEGRATED_CRT_ALLOC=path/to/allocator flag (supports rpmalloc|mimalloc|snmalloc). However I tried doing that a few months ago, and while the llvm builds seemed to work fine, rustc_llvm failed to build using a version of LLVM built with mimalloc or snmalloc (I didn't end up testing rpmalloc at the time). The errors at the time were: for snmalloc error: renaming of the library 'INCLUDE' was specified, however this crate contains no '#[link(...)]' attributes referencing this library for mimalloc the error was the same, except it was F instead of INCLUDE

The LLVM pr (https://reviews.llvm.org/D71786) also showed some pretty major performance gains when it was implemented.

[jyn514]

@michaelwoerister also suggested in #49180 that we could set codegen-units=1 for the compiler (we already do that for std).

[the8472]

x86_64: Update to v2/v3/APX sometime in the future. So far, the perf. wins haven't been convincing enough to upgrade, because it will reduce compatibility for older CPUs.

Note that there's a bit of a catch-22. We could start adding specialized SIMD impls for some important core routines if std were built with a higher baseline, which would increase the performance delta. But as long as such builds don't exist it's hardly worth it because it'll only benefit users of -Zbuild-std.

Do any of the ARM targets offer a baseline that's high enough to include fancy simd features? Maybe some generic simdification work on those could show potential benefits that would be enabled on top of what's gained by compiling with a higher baseline.

Or maybe an AVX2 codepath could be added to hashbrown since that can benefit some users even without build-std. @Amanieu have there been any experiments in that direction?

[Mark-Simulacrum]

Apple aarch64 should have a very modern baseline.

[Kobzol]

Note that there's a bit of a catch-22. We could start adding specialized SIMD impls for some important core routines if std were built with a higher baseline, which would increase the performance delta

That's a very good point, I agree with that!

I think that we could start with the compiler (and its stdlib), to potentially make it faster, but still keep the actual Linux x64 target without v2/v3/v4 CPU features by default.

Do you have any ideas where we could start using x86 v2 CPU features?

[the8472]

I think that we could start with the compiler (and its stdlib),

Doesn't the compiler link the same stdlib it uses to build programs?

Do you have any ideas where we could start using x86 v2 CPU features?

Adopting the utf8 validation impl from simdutf8. Other than that it'll need some exploration. Maybe the stdsimd folks have some ideas on tap.
There's always a difference between "if I had all the most recent CPU features I could..." and more modest optimizations 😅

Maybe rustc hash could be replaced with a different mixing function? ... odd, I can't find the feature level of the PCLMULQDQ instruction.

[Kobzol]

Doesn't the compiler link the same stdlib it uses to build programs?

IIRC it doesn't, it has its own copy. Conceptually, it needs to be able to use to add any (target) stdlib to the resulting program to cross-compile. But I might be wrong.

[tschuett]

The targets on the Platform Support page look like legit target triples. Could you encode v4 in triple and ship two Linux versions for x86?

[Kobzol]

In theory yes, but I'm not sure if it's the best solution. Maybe we could bump the defaut target to v2/v3 and keep an unoptimized v1 target for people with old CPUs. In any case, maintaining a target is not for free, so maybe there are better solutions.

To clarify, it's a very different thing to ship a v2 compiler and to make the x86 Linux target v2 by default. We're really only considering the first thing for now.

[tschuett]

Shipping a highly tuned v4 compiler with -mtune=icelake should give some speedup and you can use current cpu features: AVX512, PCLMULQDQ, ..

Haswell was launched June 4, 2013.

x86-64: CMOV, CMPXCHG8B, FPU, FXSR, MMX, FXSR, SCE, SSE, SSE2
x86-64-v2: (close to Nehalem) CMPXCHG16B, LAHF-SAHF, POPCNT, SSE3, SSE4.1, SSE4.2, SSSE3
x86-64-v3: (close to Haswell) AVX, AVX2, BMI1, BMI2, F16C, FMA, LZCNT, MOVBE, XSAVE
x86-64-v4: AVX512F, AVX512BW, AVX512CD, AVX512DQ, AVX512VL

[Kobzol]

Yes, our measurements show that v3 produces ~1-3% speedup for the compiler. But on it's own, that hasn't been worth it to use it so far, because there is non-trivial maintenance costs for doing that, plus we would drop some existing users. We'll need to tread carefully.

[the8472]

AVX-512 is not really viable for broad use because AMD only started shipping it recently and intel has only shipped it to some of their market segments (workstation/server chips) and even disabled it on some recent chips due to inconsistencies between P and E cores.
AVX2 has a much larger user base.

See https://store.steampowered.com/hwsurvey/Steam-Hardware-Software-Survey-Welcome-to-Steam?platform=linux
99% for SSE42 (~v2)
93% for AVX2 (~v3)
6.5% for AVX512 (~v4)