Performance of Rust Language [pdf]
tanelpoder
47 points
22 comments
May 25, 2026
Related Discussions
Found 5 related stories in 93.3ms across 8,444 title embeddings via pgvector HNSW
- Show HN: Rust but Lisp thatxliner · 113 pts · May 09, 2026 · 60% similar
- Rust 1.95.0 caution · 11 pts · April 16, 2026 · 60% similar
- An incoherent Rust emschwartz · 160 pts · March 23, 2026 · 58% similar
- Lisette a little language inspired by Rust that compiles to Go jspdown · 257 pts · April 05, 2026 · 56% similar
- Notes on writing Rust-based Wasm vinhnx · 218 pts · March 08, 2026 · 56% similar
Discussion Highlights (5 comments)
encodedrose
If I followed, Rust's memory safety guarantee means sacrificing roughly ~3% performance with some worst case paths being ~15% (compared to C++ performance)?
gobdovan
Rust is in an awkward position of being already complicated enough that adding proofs for skipping bounds checks probably will not happen for a long time, even though this kind of low-level operation is where a lot of optimisation is lost. Compounding on this, Rust is also unstable underneath, since there is no public, stable contract for carrying high-level semantics from HIR into MIR. Because these high-level invariants are lost during compilation, the compiler cannot easily use them to prove and eliminate low-level safety checks. But even if the frontend was perfect, Rust relies on LLVM's language-neutral SCEV, which operates purely on low-level math and cannot reason about high-level language semantics. Ultimately, a lot of things would need to change for Rust to pay no performance for safety features.
Animats
There's a discussion of "delayed bounds checking", but not "hoisted bounds checking", where bounds checking is done early. Consider let mut tab: [usize;100] = [0;100]; ... for i in 0..101 { tab[i] = i; } This must panic at i=100. Panic becomes inevitable at entry to the loop. Is the compiler entitled to generate a check that will panic at loop entry? The slides suggest that Rust does not hoist such checks, and, so, with nested loops, it has trouble getting checks out of the loop, which prevents vectorization.
jandrewrogers
I would summarize it thusly: Rust is roughly as performant as C. This matches my experience and Rust is more ergonomic than C in many regards. The caveat is that modern C++ is notably more performant than C and by implication Rust. This also matches my experience for both C and Rust. I think most of this is attributable to the ergonomics of compile-time expressiveness. C++ can effortlessly do things that require mountains of ugly boilerplate and macros in C or Rust. In principle they can express the same things but no one wants to write or deal with that ugly boilerplate so the equivalency is never realized in real code bases. Zig is interesting because it slots in as a C-like language with a competent and expressive compile-time story. I don’t use Zig but I recognize its game.
_alphageek
I would have liked to have the checks-off delta plotted across rustc versions - the deck notes this stuff moves non-monotonically, so a trend line would say more than a single-version snapshot.