←back to thread

Zlib-rs is faster than C

(trifectatech.org)
341 points dochtman | 1 comments | 16 Mar 25 19:35 UTC | HN request time: 0.233s | source
Show context
IshKebab ◴[16 Mar 25 19:55 UTC] 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 ◴[16 Mar 25 20:05 UTC] 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 #
solidsnack9000 ◴[17 Mar 25 04:56 UTC] No.43385335[source]▶
I'm not sure why people say this about certain languages (it is sometimes said about Haskell, as well).

The code has a C style to it, but that doesn't mean it wasn't actually written in Rust -- Rust deliberately has features to support writing this kind of code, in concert with safer, stricter code.

Imagine if we applied this standard to C code. "Zlib-NG is basically written in assembler, not C..." https://github.com/zlib-ng/zlib-ng/blob/50e9ca06e29867a9014e...

replies(1): >>43387472 #
ajross ◴[17 Mar 25 11:49 UTC] No.43387472[source]▶
> Imagine if we applied this standard to C code. "Zlib-NG is basically written in assembler, not C..."

We absolutely should, if someone claimed/implied-via-headline that naive C was natively as fast as hand-tuned assembly! This kind of context matters.

FWIW: I'm not talking about the assembly in zlib-rs, I was specifically limiting my analysis to the rust layers doing memory organization, etc... Discussing Rust is just exhausting. It's one digression after another, like the community can't just take a reasonable point ("zlib-rs isn't a good example of idiomatic rust performance") on its face.

replies(3): >>43388819 #>>43396152 #>>43396173 #
1. solidsnack9000 ◴[17 Mar 25 14:11 UTC] No.43388819[source]▶
I'm not sure anyone really believes `zlib-rs` is a good example of idiomatic Rust performance, though

Maybe the reason I think that is because I've written Rust for a variety of purposes (web application, database bindings, high performance parser) so I account for the "register" of Rust that is appropriate without thinking about it.

https://en.wikipedia.org/wiki/Register_(sociolinguistics)

It might be that a simple description like the headline leads some people to believe they could write Rust the easy way and get code that's as fast as writing "Rust the hard way".

However, that is different than what you earlier said -- "It's... basically written in C.". I have actually written Rust programs where some parts were literally written in C and linked in -- in order to build functioning plugins -- and there is a world of difference with that.

Regarding

Discussing Rust is just exhausting. It's one digression after another, like the community can't just take a reasonable point ("zlib-rs isn't a good example of idiomatic rust performance") on its face.

I'm just not sure what to say to this. What do you expect from me, here?