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, and more recently aarch64-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.

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

PGO

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

• Linux x64: Utilize PGO for rustc linux dist builds #80262, merged 2020-12-23.
• Linux AArch64: ci: Enable opt-dist for dist-aarch64-linux builds #133807, merged 2025-01-15
• 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.

• Linux x64:
  • rustc front-end: Enable LTO for rustc_driver.so #101403, merged 2022-10-24.
  • LLVM: done some time ago.
• Linux AArch64: ci: Enable opt-dist for dist-aarch64-linux builds #133807
• 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]: currently statically linked.

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.

• Linux x64:
  • 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.
• Linux AArch64: waiting for BOLT bugs to be fixed on ARM
• 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.

• using lld by default on x86_64-unknown-linux-gnu:
  • on nightly: Enable rust-lld on nightly x86_64-unknown-linux-gnu #124129, merged 2024-05-17
  • on stable

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.