←back to thread

Zlib-rs is faster than C

(trifectatech.org)
341 points dochtman | 4 comments | | HN request time: 0.001s | source
Show context
IshKebab ◴[] No.43381686[source]
It's barely faster. I would say it's more accurate to say it's as fast as C, which is still a great achievement.
replies(3): >>43381694 #>>43381776 #>>43381791 #
ajross ◴[] No.43381791[source]
It's... basically written in C. I'm no expert on zlib/deflate or related algorithms, but digging around https://github.com/trifectatechfoundation/zlib-rs/ almost every block with meaningful logic is marked unsafe. There's raw allocation management, raw slicing of arrays, etc... This code looks and smells like C, and very much not like rust. I don't know that this is a direct transcription of the C code, but if you were to try something like that this is sort of what it would look like.

I think there's lots of value in wrapping a raw/unsafe implementation with a rust API, but that's not quite what most people think of when writing code "in rust".

replies(6): >>43381833 #>>43381841 #>>43381849 #>>43382402 #>>43383336 #>>43385335 #
oneshtein ◴[] No.43381849[source]
Cannot understand your complain. It written in Rust, but for you it looks like C. So what?
replies(2): >>43382043 #>>43382101 #
ajross ◴[] No.43382101[source]
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.

replies(1): >>43382366 #
sedatk ◴[] No.43382366[source]
Rust'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

replies(1): >>43383496 #
ajross ◴[] No.43383496[source]
But 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.
replies(2): >>43383632 #>>43385001 #
1. steveklabnik ◴[] No.43383632{3}[source]
> This isn't using the Rust runtime heap,

Rust does not have a specific "Rust runtime heap."

replies(1): >>43386173 #
2. IshKebab ◴[] No.43386173[source]
It does, it has a default global heap allocator.
replies(2): >>43386624 #>>43389482 #
3. simonask ◴[] No.43386624[source]
That's not a "Rust runtime", that's an extension point. The default setting is `malloc()`.
4. steveklabnik ◴[] No.43389482[source]
That'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.