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

311–320 of 492 posts

Re: Zlib-rs is faster than C

#311

Post by serial_dev »

Someone wrote: post #298
tdiff wrote: post #32

Earlier quoted context omitted.

Nevertheless Russinovich actually says something in the lines of "simple rewriting in rust made some our code 5-15% faster (without deliberate optimizations)": https://www.youtube.com/watch?v=1VgptLwP588&t=351s

Without analysis as to what caused that, that statement is meaningless. For example, he says they didn’t set out to improve the code, but they were porting decennia-old C code to rust. Given the subject (truetype font parsing and rendering), my guess would be that the original code had more memory copies copying data out of the font data because rust makes it easier to safely avoid that (in which case the conclusion…

I understand their improvement figures exactly as you wrote, "C could be as fast, but with a lot more effort".

Yes, if your code in Lang-X is faster than C, it's almost certainly a skill issue somewhere in the C implementation.

However, in the day-to-day, if I can make my code run faster in Lang-X than C, especially if I'm using Lang-X for only a couple of months and C potentially for decades, that is absolutely meaningful. Sure, we can make the C code just as fast, but it's not viable to spend that much time and expertise on every small issue.

Outside of "which lang is better" discussions on online forums, it doesn't matter how fast you can theoretically make your program, it matters how fast you actually make it with the constraints your business have (time usually).

Re: Zlib-rs is faster than C

#313

Post by simonask »

chjj wrote: post #247
pdimitar wrote: post #191

Earlier quoted context omitted.

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.

I mean, aren't you having such an interaction right now? Do you find this discussion toxic?

Re: Zlib-rs is faster than C

#314

Post by immibis »

Aurornis wrote: post #29
YZF wrote: post #18

I found out I already know Rust: unsafe { let x_tmp0 = _mm_clmulepi64_si128(xmm_crc0, crc_fold, 0x10); xmm_crc0 = _mm_clmulepi64_si128(xmm_crc0, crc_fold, 0x01); xmm_crc1 = _mm_xor_si128(xmm_crc1, x_tmp0); xmm_crc1 = _mm_xor_si128(xmm_crc1, xmm_crc0); Kidding aside, I thought the purpose of Rust was for safety but the keyword unsafe is sprinkled liberally throughout this library. At what point does it really stop mat…

Using unsafe blocks in Rust is confusing when you first see it. The idea is that you have to opt-out of compiler safety guarantees for specific sections of code, but they’re clearly marked by the unsafe block. In good practice it’s used judiciously in a codebase where it makes sense. Those sections receive extra attention and analysis by the developers. Of course you can find sloppy codebases where people reach for u…

Clearly marking unsafe code is no good for safety, if you have many marked areas.

Some codebases, you can grep for "unsafe", find no results, and conclude the codebase is safe... if you trust its dependencies.

This is not one of those codebases. This one uses unsafe liberally, which tells you it's about as safe as C.

"unsafe behaviour is clearly marked" seems to be a thought-stopping cliche in the Rust world. What's the point of marking them, if you still have them? If every pointer dereference in C code had to be marked unsafe (or "please" like in Intercal), that wouldn't make C any better.

Re: Zlib-rs is faster than C

#315

Post by immibis »

oneshtein wrote: post #257
throwaway2037 wrote: post #234

Earlier quoted context omitted.

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

AI rewrote to avoid undefined behavior: int average(int x, int y) { long sum = (long)x + y; if(sum > INT_MAX || sum

We're about to see a huge uptick in bugs worldwide, aren't we?

Re: Zlib-rs is faster than C

#316

Post by pdimitar »

simonask wrote: post #313
chjj wrote: post #247

Earlier quoted context omitted.

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.

I mean, aren't you having such an interaction right now? Do you find this discussion toxic?

What I find toxic is the claim of zealotry when I can't see any, not on HN anyway.

So I called the poster out to show proof. So far there's none, except one Twitter post (because we all know that's the best technical discussion forum on the planet, clearly) which does not surprise me at all.

So they are the ones who get triggered by something that does not exist.

That is what is toxic.

If you go around claiming fantasies and people call you out then that falls more under curiosity and discussion. Not toxicity.

Re: Zlib-rs is faster than C

#317

Post by simonask »

IshKebab wrote: post #293
steveklabnik wrote: post #172

Earlier quoted context omitted.

> This isn't using the Rust runtime heap, Rust does not have a specific "Rust runtime heap."

It does, it has a default global heap allocator.

That's not a "Rust runtime", that's an extension point. The default setting is `malloc()`.

Re: Zlib-rs is faster than C

#318

Post by pdimitar »

chjj wrote: post #247
pdimitar wrote: post #191

Earlier quoted context omitted.

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.

Very weird. Maybe you can point us at these "every interaction" so we can see for ourselves?

Toxic people are everywhere on the net. That's not an interesting insight. If you point us at some lunatic on Twitter who loses their marbles over everything, that's not interesting either.

Do you get trolled on actual technical forums though?

Re: Zlib-rs is faster than C

#319

Post by saagarjha »

throwaway2037 wrote: post #241
gf000 wrote: post #148

Earlier quoted context omitted.

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.

I take that you consider most major projects written in C to not be "good"?

Re: Zlib-rs is faster than C

#320

Post by saagarjha »

throwaway2037 wrote: post #245
vlovich123 wrote: post #152

Earlier quoted context omitted.

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"?

For example many autovectorizers get upset if you put control flow in your loop
Post reply on HN