The Rust Performance Book | Hacker News Reader

The Rust Performance Book

nnethercote.github.io

153 pointswalterbell19 comments

Nicholas Nethercote is, of course, the author of the "How to speed up the Rust compiler" series of articles [1], which I found fascinating. He spent quite some time at Mozilla optimizing rustc internals.

Kudos for his work, and for making Rust compilation faster for all of us.

^[1]: https://blog.mozilla.org/nnethercote/category/rust/

I've skimmed through the book, is there no advice on things like cache locality? Cache misses and the like? SOA instead of AOS? These are like the central issues of high performance code once you get past "maybe don't heap allocate in a hot loop" or whatever.

It looks like chapters 8 and 16 (at least) obliquely refer to those ideas. Perhaps if there are specific topics you think would be useful, you could open an issue or a PR?

That being said, it looks to me like the main concern here is surfacing Rust specifics, rather than general performance concerns.

for the real work you'll have to use C. Rust use case is for crafting cool new age hacker news stories.

The book is primarily about Rust-specific things. Section 1 says: "Some of the techniques within are entirely Rust-specific, and some involve ideas that can be applied (often with modifications) to programs written in other languages." I will clarify this.

Having said that, Section 16 does have general optimization advice, and I will consider adding some brief notes about the things you mentioned there.

Thanks for the suggestion.

Those aren't particularly Rust specific, except when Rust constructs make those things easier/ harder, which is how they're brought up.

Someone could explain things like cache via Rust, but the information is language agnostic, whereas this book is very much Rust specific.

This taught me about ahash (https://crates.io/crates/ahash). It uses the aesenc (https://www.felixcloutier.com/x86/aesenc) instruction as a high-quality fast permutation. Smart and fun.

'Book' seems a grand title for what could essentially fit in a long blog post? One thing I've been wondering recently is in relation to Rust's overhead for dynamic bounds checks. I know in many cases these can be avoided/elided (e.g. using iterators), but are there any common cases where this isn't possible? Or alternatively where convincing the compiler to remove them introduces a significant amount of complexity?

when iterators can’t be used and llvm can’t elide you can use unsafe to elide by hand. the scenarios where the performance matters and iterators can’t be used are thankfully pretty rare so not much unsafe has to be used for this reason.

Is there any way to treat bounds check as a warning to eliminate it early?

not globally no. isolating that kind of behavior to unsafe blocks is a priority to make it easier to audit. if you wanted globally unsafe memory C or Zig would be a more sensible choice

A nice method I've found (and seems popular) is to use unsafe but use a debug_assert!. That way your tests will fail loudly if you hit the assertion, but you won't take a hit in production.

Book is what this site layout is called in the community, see also:

Rust Book: https://doc.rust-lang.org/book

Rust Rand Book: https://rust-random.github.io/book

Rust WebAssembly Book: https://rustwasm.github.io/book

Rust Unstable Book: https://doc.rust-lang.org/beta/unstable-book/index.html

Rustonomicon: https://doc.rust-lang.org/beta/nomicon/index.html

Cargo Book: https://doc.rust-lang.org/cargo

Which seems to be generated by https://github.com/rust-lang/mdBook

Now, I don't see why "book" should seem so grand. Remember when reference books would come out as a "bible"?

As for bounds check, here's a relevant issue raised on rand crate: https://github.com/rust-random/rand/issues/592

One can dig for a kind of "unsafe assertions" with https://doc.rust-lang.org/std/hint/fn.unreachable_unchecked.... (so the random code, for example, could have before returning value 'if x >= upper { unsafe { unreachable_unchecked() } }')

Yep. I'll also add that "books" are typically used for higher-level, more narrative pieces of documentation, vs the API-level `rustdoc`-generated documentation.

Thanks for the links. If the intention is to expand over time then I agree it makes sense.

If you're really convinced that it's safe to elide them and you can't get it to work using iterators or asserts then you can use `unsafe` to bypass the checks. But I don't think this is necessary in most cases.

The expectation for a blog post is that it captures things at a single moment in time. To me, "book" implies something that will be continually updated and maybe expanded.

Strange, I feel the opposite, just because of the medium that books tend to be written in - ink.

To me a book has chapters, sequence, etc.

Yes, it you get multiple editions of books over multiple years, whereas blog posts don't get continuously revised.

Reply on news.ycombinator.com