It's actually pronounced @lqd@tutut.delire.party
France
Joined April 2008
- Tweets15.5K
- Following950
- Followers673
- Likes8.9K
If you care about rust compile times, this may be of interest: we've recently switched rustc to use lld on x64 linux (on nightly only for now to expand testing, before enabling it on stable).
I wrote more about it, with details and perf improvements, in blog.rust-lang.org/2024/05/1…
rustc lint idea: when a function returns a Result, whose Err type allocates, and no one is ever reading that result's error.
(With all due respect to @wesleywiser, the brains and auteur behind this operation)
– Jerry, I just wanted to pass a linker flag. ONE LINKER FLAG!!!
*Kramer bursts in*
– Have you guys tried mold yet? You gotta try mold! Makes your compile times go zip
The eagle has landed. To help with the switch-to-LLD effort, try `-Clink-self-contained=+linker -Clinker-flavor=gnu-lld-cc -Zunstable-options` on nightly and give us feedback!
(and in case this website continues to self-implode, I'll also be on mastodon tutut.delire.party/@lqd)
Small executables are overly represented, but results are still looking good.
Real world binaries like `ripgrep` and `exa` are still greatly improved with lld.
(perf.rust-lang.org/compare.h…)
Cheeky but realistic.
ALT A screenshot of my terrible rustc code with the cheeky but realistic comment: "Welcome to Even More Inefficient City. Population: this code"
If your from-scratch check and debug builds are bottlenecked on build scripts and proc-macros, try this in your Cargo.toml, it may help:
[profile.dev.build-override]
debug = false
strip = "debuginfo"
incremental = false
There are caveats though, read on.
I'm still working on a cargo PR, esp. for the most significant improvement, removing debuginfo (but that may also require rustc changes).
In the meantime, gist.github.com/lqd/cb65b858… may help.
There are a bunch of improvements we can make there, so stay tuned, or join us and help!
We intern const allocations, and happen to be hashing their bytes and their 1/8th-sized initialization mask.
In some cases, statics can be big, e.g. megabytes in our CTFE stress test. Turns out making the hash function worse helps this benchmark...
We've recently added more info about proc-macro expansions to rustc's self-profiler, to help diagnose compilation slowness issues.
It was tough to investigate before: they were being counted with regular macros.
(We'll work on surfacing stats for macros as well in the future)
To see if they are causing issues in general, `-Zself-profile` will now show the `expand_proc_macro` stats for all proc-macros used in the crate.
Since we're currently looking into this, another quick one.
I'm not sure how well-known `rust-lld` is (it's the lld we build and package for at least the most common tier1 targets). It's super easy to try.
lld is supposedly faster.
On nightly: on linux (where it's more tested in practice), try it with `-Zgcc-ld=lld`. It should also work on intel osx.
On windows, I believe `-Clinker=rust-lld.exe` should be enough and work on stable (but am not sure about the perf there).
Let me know if you try it and have problems: we'll want to track those, e.g. by filing an issue at github.com/rust-lang/rust/is…), and whether it helps on your project.