Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zlib-rs is faster than C

trifectatech.org

Post reply on HN
Print view View original

241–250 of 492 posts

Re: Zlib-rs is faster than C

#241

Post by throwaway2037 »

gf000 wrote: post #148
uecker wrote: post #126

Earlier quoted context omitted.

What is true is that there are more operations in C which can cause undefined behavior and those are more densely distributed over the C code, making it harder to screen for undefined behavior. This is true and Rust certainly has an advantage, but it not nearly as big of an advantage as the "Rust is safe" (please do not look at all the unsafe blocks we need to make it also fast!) and "all C is unsafe" story wants you…

Rust is plenty fast, in fact there are countless examples of safe rust that will trivially beat out C in performance due to no aliasing, enabling better vectorization among others. Let alone being simply a more expressive language and allowing writing better optimizations (e.g. small strings, vs the absolutely laughable c-strings that perform terribly, but also you can actually get away with sharing more stuff in mem…

    > absolutely laughable c-strings that perform terribly
Not much being said here in 2025. Any good project will quickly switch to a tiny structure that holds char* and strlen. There are plenty of open source libs to help you.

Re: Zlib-rs is faster than C

#242

Post by pveierland »

ForTheKidz wrote: post #235
pveierland wrote: post #230

Earlier quoted context omitted.

One big part I've noticed when working in rust is that, because the compilation and analysis checks you're given are so much stronger than in C or C++, and because the ecosystem of crates is so easy to make use of, I'll generally be able to make use of more advanced algorithms and methods. I'm currently working with ~150 dependencies in my current project which I know would be a major hurdle in previous C or C++ proj…

Everything you said is correct of course, but the idea of auditing 150 dependencies makes me feel ill. It's essentially impossible for a single person.

Oh, absolutely. Software cannot scale without trust. No single person is capable of auditing their browser or operating system either.

Re: Zlib-rs is faster than C

#243

Post by oneshtein »

Alifatisk wrote: post #42
oneshtein wrote: post #17

Earlier quoted context omitted.

Cannot understand your complain. It written in Rust, but for you it looks like C. So what?

So, it is basically like it was written in C.

Yes, it's possible to write in Rust like in C. This code is example of that. You can even use automatic code converter to convert C into Rust.

Re: Zlib-rs is faster than C

#244

Post by throwaway2037 »

NobodyNada wrote: post #155
onnimonni wrote: post #147

Earlier quoted context omitted.

Would someone with more experience be able to explain to me why can't these operations be "safe"? What is blocking rust from producing the same machine code in a "safe" way?

Rust's raw pointers are more-or-less equivalent to C pointers, with many of the same types of potential problems like dangling pointers or out-of-bounds access. Rust's references are the "safe" version of doing pointer operations; raw pointers exist so that you can express patterns that the borrow checker can't prove are sound. Rust encourages using unsafe to "teach" the language new design patterns and data structur…

Why does Vec need to have any unsafe code? If you respond "speed"... then I will scratch my chin.

    > For example, the Vec type is a wrapper around a raw pointer, length, and capacity; and exposes a safe interface allowing you to create, manipulate, and access vectors with no risk of pointer math going wrong -- assuming the people who implemented the unsafe code inside of Vec didn't make a mistake, the external, safe interface is guaranteed to be sound no matter what external code does.
I'm sure you already know this, but you can do exactly the same in C by using an opaque pointer to protect the data structure. Then you write a bunch of functions that operate on the opaque pointer. You can use assert() to protect against unreasonable inputs.

Re: Zlib-rs is faster than C

#245

Post by throwaway2037 »

vlovich123 wrote: post #152
onnimonni wrote: post #147

Earlier quoted context omitted.

Would someone with more experience be able to explain to me why can't these operations be "safe"? What is blocking rust from producing the same machine code in a "safe" way?

Those specific functions are compiler builtin vector intrinsics. The main reason is that they can easily read past ends of arrays and have type safety and aliasing issues. By the way, the rust compiler does generate such code because under the hood LLVM runs an autovectorizer when you turn on optimizations. However, for the autovectorizer to do a good job you have to write code in a very special way and you have no w…

    > However, for the autovectorizer to do a good job you have to write code in a very special way
Can you give an example of this "very special way"?

Re: Zlib-rs is faster than C

#246

Post by solidsnack9000 »

ajross wrote: post #8
IshKebab wrote: post #2

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.

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 we…

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...

Re: Zlib-rs is faster than C

#247

Post by chjj »

pdimitar wrote: post #191
chjj wrote: post #133

Earlier quoted context omitted.

[flagged]

I am hopping on Rust threads on HN very regularly and I have to tell you my anecdotal experience. Which is: people complaining about Rust zealots are much more than actual Rust zealots. Thinking of it, I haven't seen a proper Rust zealot on HN for at least a year at this point. So I don't know, maybe do less cheap digs. Tearing down straw men is pretty boring to watch.

We have very different experiences then. Don't know what to tell you.

Every interaction I've had with a rust programmer has led me to believe they are a toxic community of cultists. It's unlike any programming community I've seen.

Re: Zlib-rs is faster than C

#248

Post by jandrewrogers »

throwaway2037 wrote: post #234
masfuerte wrote: post #190

Earlier quoted context omitted.

int average(int x, int y) { return (x+y)/2; }

I assume you are hinting at 'int' is signed here? And, that signed overflow is UB in C? Real question: Ignoring what the ISO C language spec says, are there any modern hardware platforms (say: ARM64 and X86-64) that do not use two's complement to implement signed integers? I don't know any. As I understand, two's complement correctly supports overflow for signed arithmetic. I might be old, but more than 10 years ago,…

At least in recent C++ standards, integers are defined as two’s complement. As a practical matter what hardware like that may still exist doesn’t have a modern C++ compiler, rendering it a moot point.

UB in C is often found where different real hardware architectures had incompatible behavior. Rather than biasing the language for or against different architectures they left it to the compiler to figure out how to optimize for the cases where instruction behavior diverge. This is still true on current architectures e.g. shift overflow behavior which is why shift overflow is UB.

Re: Zlib-rs is faster than C

#249

Post by fasterthanlime »

chillingeffect wrote: post #224
sunshowers wrote: post #123

Earlier quoted context omitted.

No, C lacks encapsulation of unsafe code. This is very important. Encapsulation is the only way to scale local reasoning into global correctness.

Eh. Good C programmers know what's safe and what's not. Often comments call out sketchy stuff. Just because it's not a language keyword, doesnt mean it's not called out. Bad C programmers though? Their stuff is more dangerous and they don't know when and don't call it out and should probably stick to Rust.

True! Only, Good C programmers don’t exist.

Re: Zlib-rs is faster than C

#250

Post by throwaway2037 »

sunshowers wrote: post #122
chongli wrote: post #47

Earlier quoted context omitted.

Isn't it the case that once you use unsafe even a single time, you lose all of Rust's nice guarantees? As far as I'm aware, inside the unsafe block you can do whatever you want which means all of the nice memory-safety properties of the language go away. It's like letting a wet dog (who'd just been swimming in a nearby swamp) run loose inside your hermetically sealed cleanroom.

What language is the JVM written in? All safe code in existence running on von Neumann architectures is built on a foundation of unsafe code. The goal of all memory-safe languages is to provide safe abstractions on top of an unsafe core.

    > What language is the JVM written in?
I am pretty sure it is C++.

I like your second paragraph. It is well written.

Post reply on HN