Zlib-rs is faster than C
trifectatech.org
Zlib-rs is faster than C
1–10 of 492 posts
Re: Zlib-rs is faster than C
#2It's barely faster. I would say it's more accurate to say it's as fast as C, which is still a great achievement.
Re: Zlib-rs is faster than C
#3It's barely faster. I would say it's more accurate to say it's as fast as C, which is still a great achievement.
But it is faster. The closer to theoretical maximum the smaller the gains become.
Re: Zlib-rs is faster than C
#4"faster than C" almost always boils down to different designs, implementations, algorithms, etc.
Perhaps it is faster than already-existing implementations, sure, but not "faster than C", and it is odd to make such claims.
Re: Zlib-rs is faster than C
#5It's barely faster. I would say it's more accurate to say it's as fast as C, which is still a great achievement.
But it is faster. The closer to theoretical maximum the smaller the gains become.
Zlib-ng is between a couple and multiple times away from the state of the art[1], it’s just that nobody has yet done the (hard) work of adjusting libdeflate[2] to a richer API than “complete buffer in, complete buffer out”.
Re: Zlib-rs is faster than C
#6It's barely faster. I would say it's more accurate to say it's as fast as C, which is still a great achievement.
"Barely" or not is completely irrelevant. The fact is that it's measurably faster than the C implementation with the more common parameters. So the point that you're trying to make isn't clear tbh.
Also I'm pretty sure that the C implementation had more man hours put into it than the Rust one.
Re: Zlib-rs is faster than C
#7You mean the implementation is faster than the one in C. Because nothing is “faster than C”.
Re: Zlib-rs is faster than C
#8It's barely faster. I would say it's more accurate to say it's as fast as C, which is still a great achievement.
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".
Re: Zlib-rs is faster than C
#9"faster than C" almost always boils down to different designs, implementations, algorithms, etc. Perhaps it is faster than already-existing implementations, sure, but not "faster than C", and it is odd to make such claims.
... because by "C" we mean handwritten inline assembler.
Typical realworld C code uses \0 terminated strings and strlen() with O(len^2) complexity.
Re: Zlib-rs is faster than C
#10You mean the implementation is faster than the one in C. Because nothing is “faster than C”.
Tachyons?