Shnatsel

shnatsel wrote a post on bounds checking performance implications in Rust. Money quote: > The real-world performance impact of bounds checks is surprisingly low. > The greatest impact I’ve ever seen on real-world code from removing bounds checks alone was *15%,* but the typical gains are in *1% to 3% range,* and even that only happens in code that does a lot of number crunching. > You can occasionally see greater impact (as we’ll see soon!) if removing bounds checks allows the compiler to perform other optimizations. > Still, performance of code that’s not doing large amounts of number crunching will probably [not be impacted by bounds checks](https://blog.readyset.io/bounds-checks/) at all. It is, of course, not universally applicable, so read the post for full details: https://shnatsel.medium.com/how-to-avoid-bounds-checks-in-rust-without…

> The article mentions bounds checks, but gives no measurements. Have they ever measured? Related, the prominent Rust community member "Shnatsel" wrote an article [1] about exactly that in January. It's a great look at the problem, and gives some actual data to evaluate with. [1]: https://shnatsel.medium.com/how-to-avoid-bounds-checks-in-rust-without…

> a nice low-level language The usability is not great, too opinionated. For example, they have decided their strings are guaranteed to contain valid UTF-8. Many external components (like Linux kernel) don’t have these guarantees, so the Rust has another OsString type for them. I think Rust is the only language which does that. The rest of them are fine keeping invalid UTF8 / UTF16 in their strings. > proper and easy to use iterators C++/11 introduced range-based for loops, they make iterators very easy to use. > nice tooling Packages are OK I guess, but I think other classes of tools are lacking. For example, I can’t imagine working on any performance critical low-level code without a good sampling profiler. > ANY, really? Yes. Even very simple data structures like std::vec::Vec require unsafe code, they call unsafe APIs like alloc::alloc for memory management. This can, and did, cause security bugs: https://shnatsel.medium.com/how-rusts-standard-library-was-vulnerable-… By comparison, modern C# is memory safe all the way down, possible to implement even very complicated data structures without a single line of unsafe code. The collection classes from the standard library don’t use unsafe code either.

https://shnatsel.medium.com/do-not-run-any-cargo-commands-on-untrusted… > any command starting with cargo can run arbitrary code when operating on an untrusted repository, and should be treated the same as cargo run.

> Yes. Java and python are not competitive for graphics and audio processing. Because Python is an interpreted language and Java has garbage collection, not because they have bounds checking. Using a language like Rust the bounds checking overhead compared to C code is usually minimal, like 0-5%. The compiler can even optimize away many bounds checks (safely) if you structure your code properly, such as with iterators. Here's an example article : https://shnatsel.medium.com/how-to-avoid-bounds-checks-in-rust-without… Make sure you read the note about how the author was mistaken about the 15% speedup from bounds checking. The actual bounds check change was much less, like a couple percent. You can even structure your code so that the bounds check disappears altogether when the compiler can confirm safety at compile time.

> Writing the implementation in Rust does sigh, not true. https://tgrez.github.io/posts/2022-06-19-buffer-overflow-in-rust.html https://shnatsel.medium.com/how-rusts-standard-library-was-vulnerable-… "This is a buffer overflow bug in the standard library’s implementation of a double-ended queue." "Rust will panic if you attempt to write out of bounds." Writing the implementation will increase memory safety but only if the implementation adheres strictly to safe Rust - which means even avoiding ANY packages that use unsafe features. The fact Rust can pull in any package that has an unsafe {} block means you're not promised to be safe. The equivalent could be said about writing the implementation in JavaScript, Python, etc... (that they protect against buffer overflows)

> What worries me is that when it comes to safety, surely the chain is as strong as the weakest link? You declare one thing unsafe, and then suddenly, all bets are off. And maybe you don't even know that what you're doing is unsafe. Yes, you are correct. If some code or module contains a memory safety or data race bug, then the code which uses it could realize that bug in the form of a crash or race. This paper is not analyzing code that contains a memory safety or data race bug, but instead, code that the Rust compiler cannot prove doesn't have such a bug. That is a big difference. Let's take your example. The questions you bring up are good ones. Fiddling with registers may indeed require atomic in the presence of multiple threads using that register. Or, if you can guarantee only one thread touches those registers, it may not. In both use cases, I'd like the compiler to help me verify that those conditions are met. A Rust approach to this problem (verified empirically by the paper) would be to create a module, function, or trait that enforces the invariants we need. Such an abstraction might contain a bug that causes the codebase to be unsafe. But when debugging that, we shouldn't have to look over the whole codebase for register writes but rather in just one place. > Suppose you have an ISR (interrupt service routine) that wants to toggle a GPIO pin. From whence does it borrow the privilege to set the pin? Assuming we are protecting the pin with atomics, the ISR…