4 ms·
It doesn't exploit (and in fact deliberately evades) Rust's signature memory safety features. The impression from the headline is "Rust is as fast as C now!",
by ajross 2y ago
It doesn't exploit (and in fact deliberately evades) Rust's signature memory safety features. The impression from the headline is "Rust is as fast as C now!", but in fact the subset of the language that has been shown to be as fast as C is the subset that is basically isomorphic to C.
The impression a naive reader might take is that idiomatic/safe/best-practices Rust has now closed the performance gap. But clearly that's not happening here.
- sedatk 2y agoRust's many memory safety features (including the borrow checker) are still enabled in unsafe Rust blocks. For more information: https://news.ycombinator.com/item?id=43382176 https://news.ycombinator.com/item?id=43382176
- ajross 2y agoBut again, not exploited by the code in question. This isn't using the Rust runtime heap, it's doing its own thing with raw pointers/indexing, and even seems to have its own allocator.
- steveklabnik 2y ago> This isn't using the Rust runtime heap, Rust does not have a specific "Rust runtime heap."
- IshKebab 2y agoIt does, it has a default global heap allocator.
- simonask 2y agoThat's not a "Rust runtime", that's an extension point. The default setting is `malloc()`.
- steveklabnik 2y agoThat's not part of Rust, that's a feature of its standard library. This is the same as C, where a freestanding implementation doesn't include malloc. Put another way, there's no issues with a library using its own heap if it wants to.
- ComputerGuru 2y agoThat is not correct; in another comment you can see where the code takes advantage of the rust-specific &mut notation to use a fast memcpy for non-overlapping pointers.