Add alternative linker to the build performance guide #15991
Conversation
rustbot
added
A-documenting-cargo-itself
There was a problem hiding this comment.
This reminds maybe we should consider a cargo native lld option for build.linker: #11378.
There was a problem hiding this comment.
That might be nice indeed, but the situation with linkers is a bit complicated. You can use the self-contained LLD, or an external LLD, on Linux you invoke LLD through cc and -fuse-ld=lld, while elsewhere through -Clinker, if the linker is not lld, but something else unsupported by the CC driver, it cannot be specified by name, but has to be passed through some hacks with an absolute path.. it's quite messy.
This is also tricky because the possible gains are very platform specific.
This has enough nuance that I don't think that style works well here
This depends.
Can't the linker help check builds when proc macros and build scripts are present? Granted, less is being linked so maybe its unnoticable. Discussing benefitted workflows seems reasonable. |
It will help somewhat, but these crates are typically rather small, and only compiled "once", so it won't be noticeable for incremental rebuilds, while linking time for the main binary can be quite noticeable for rebuilds. I split the benefits into "code generation" (build) and "build times" (check + build). |
|
|
||
| Trade-offs: | ||
| - ✅ Faster build times | ||
| - ✅ Faster code generation (`cargo build`) |
There was a problem hiding this comment.
imo that is too jargony without the surrounding context. When I see code generation, I think of the type of thing build scripts usually do
There was a problem hiding this comment.
Should I create some basic terminology at the start of the page, where we'll say that compilation is split into three categories (frontend, backend, codegen), and then we'll say in each mechanism which of these categories it helps?
| Most targets default to using the system linker, which might not be the most performant option. You can try an alternative linker to see if it improves build performance. | ||
|
|
||
| Recommendation: | ||
|
|
||
| - Install an alternative linker, for example [LLD](https://lld.llvm.org/), [mold](https://github.com/rui314/mold) or [wild](https://github.com/davidlattimore/wild) | ||
| - Configure the Rust compiler to use a different linker. The configuration depends on the used linker and operating system. For Linux and the LLD or mold linker, you can add to your `.cargo/config.toml`: | ||
|
|
||
| ```toml | ||
| # LLD | ||
| [target.'cfg(target_os = "linux")'] | ||
| rustflags = ["-C", "link-arg=-fuse-ld=lld"] | ||
|
|
||
| # mold, if you have GCC 12+ | ||
| rustflags = ["-C", "link-arg=-fuse-ld=mold"] | ||
|
|
||
| # mold, otherwise | ||
| linker = "clang" | ||
| rustflags = ["-C", "link-arg=-fuse-ld=/path/to/mold"] | ||
| ``` | ||
|
|
||
| > Note that since Rust `1.90.0`, the `x86_64-unknown-linux-gnu` target already defaults to the LLD linker. |
There was a problem hiding this comment.
Do we have a rough feel for how fast the default linker is for each platform?
One of my concerns with this is handling the nuance of
- Going from default Linux linker to lld
- Going from lld to mold/wild
The way this is written, it makes it sound like everything is the level of gain of (1) and leaves x86_64-unknown-linux-gnu as more of a footnote. If that isn't the case, people may not be getting the gains they expect from this
Are Mac and Windows on the same level of the default Linux linker or more like lld?
There was a problem hiding this comment.
On Mac the default linker should be "fast enough", since they shipped a new implementation a few yeargs ago. On Windows I saw people mentioning that LLD helps, but not always, it's probably not such a big deal as on Linux.
The biggest jump is definitely on Linux when going from BFD to LLD. If BFD's time was 1.0, then LLD is usually something like 0.1, mold maybe 0.05 and wild 0.03 (with a very big grain of salt). So going from BFD from LLD is the most important thing, the rest starts running into diminishing returns very quickly, unless you link Chrome or something similarly gargantuan.
| [parallel-frontend-issue]: https://github.com/rust-lang/rust/issues/113349 | ||
| [build.rustflags]: ../reference/config.md#buildrustflags | ||
|
|
||
| ### Use an alternative linker |
There was a problem hiding this comment.
Are there any further linker tracking issues we should link out to, like
- lld for more Linux targets
- improving mac or windows
- switching to wild
There was a problem hiding this comment.
There is rust-lang/rust#39915 as global tracking issue for "use LLD everywhere", rust-lang/rust#71515 is for Linux (that one can probably be closed now) and rust-lang/rust#71520 for Windows.
This one is tricky, because the configuration depends on the used linker and also the OS. Should we add configuration for all of Linux, Windows and Mac?
Also I didn't like starting with one with "Recommendation: ", as I think that it deserves at least a sentence of context. Actually I'd like to add this intro context before the "Recommendation: " part to all existing sections (let me know if you agree or not).
One thing I was also considering is whether we should describe the expected wins in a more detailed fashion. For example, to answer questions like: "does this help check builds?", "does this help incremental rebuilds or full builds, or both?". Regarding the linker, it won't help at all for check builds, but on the other hand it will have an even bigger effect for incremental rebuilds than for full builds, because linking is not incremental at the moment, so it typically takes a larger % out of the total build time in incremental builds.
r? @epage