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

431–440 of 492 posts

Re: Zlib-rs is faster than C

#431

Post by serial_dev »

andai wrote: post #336
serial_dev wrote: post #311

Earlier quoted context omitted.

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

The skill issue part is a pretty interesting part of the conversation. I'm always reminded of this video, where the author writes the same program in Rust and Go. https://www.youtube.com/watch?v=Z0GX2mTUtfo > Now, the Rust version took me about five times as long as the Go version > The Go one performed almost identically well Now this was for netcode rather than number crunching. But I actually had a similar surpris…

Well, what I said is also true for Rust and Go. Sure if your Go code is faster than your Rust code, one could argue you have skill issues in Rust, but if to get the Rust program faster than your Go program requires 10x time (or more), it’s fair to say that Go is faster and simpler, even if it would be more precise to say that the Go code you can write performs as well as the Rust code you can write.

Re: Zlib-rs is faster than C

#432

Post by johnisgood »

ForTheKidz wrote: post #423
maccard wrote: post #361

Earlier quoted context omitted.

We’re talking about a rust rewrite of a fairly core level library. I don’t think C is inherently unsuitable or difficult to hire for. If the library was in Fortran then maybe. But yes you are technically correct, congratulations.

I was responding to a general claim. In any case, I certainly disagree that C is suitable in 2025 for the vast majority of possible use-cases. For fun? Sure, but not for shipping code you want to rely on. Obviously the code isn't going anywhere, and obviously we DO have reliable code we've built with C. But acting like C and Rust deliver equivalent value is simply farcical: you choose C for rapid development and chea…

Million dollar question: why Rust over ? Common Lisp? OCaml, Ada / SPARK, etc. if not C?

Re: Zlib-rs is faster than C

#433

Post by wolvesechoes »

sophacles wrote: post #413
wolvesechoes wrote: post #375

Earlier quoted context omitted.

Funny, because I could swear that for every comment that rises some criticism against Rust design/implementation/ergonomics/whatever, I find a dozen that "respectfully disagree", i.e. try very hard to deny validity of original claims. It is somewhat similar, actually, when someone states a negative opinion on Rust community and marketing around it. It is usually followed by those that say "you met wrong people". Of c…

Wait... zealotry is not "someone having a different opinion". Literally that's what you're saying: they have a different opinion therefore they're zealots! Unless people posting an opinion is itself zealotry... but in that case why are you complaining about the replies and not the comments they reply to?

It is hard to call it "literal" interpretation of my words when they do not contain any occurrence of the word "zealots".

I think exegesis is a skill you need to hone further.

Re: Zlib-rs is faster than C

#434

Post by Georgelemental »

> The C code is able to use switch implicit fallthroughs to generate very efficient code. Rust does not have an equivalent of this mechanism

Rust very much can emulate this, with `break` + nested blocks. But not if you also add in `goto` to previous branches

Re: Zlib-rs is faster than C

#435

Post by kazinator »

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 marked by the unsafe block.

Rust has macros; are macros prohibited from generating unsafe blocks, so that macro invocations don't have to be suspected of harboring unsafe code?

Re: Zlib-rs is faster than C

#436

Post by uecker »

lambda wrote: post #213
uecker wrote: post #128

Earlier quoted context omitted.

And you think one can not modularize C code and encapsulate critical buffer operations in much safer APIs? One can, the problem is that a lot of legacy C code was not written this way. Also lot of newly written C code is not written this way, but the reason is often that people cut corners when they need to get things done with limited time and resources. The same you will see with Rust.

There is no distinction between safe and unsafe code in C, so it's not possible to make that same distinction that you can in Rust. And even if you try to provide some kind of safer abstraction, you're limited by the much more primitive type system, that can't distinguish between owned types, unique borrows, and shared borrows, nor can it distinguish thread safety properties. So you're left to convention and document…

There is definitely a distinction between safe and unsafe code in C, it is just not a simple binary distinction. But this does not make it impossible to screen C for unsafe constructions and it also does not mean that detecting unsafe issues in Rust is always trivial.

Re: Zlib-rs is faster than C

#437

Post by uecker »

masfuerte wrote: post #190
wavemode wrote: post #160

Earlier quoted context omitted.

Care to share an example?

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

But this is also easy to protect against if you use the tools available to C programmers. It is part of the Rust hype that we would be completely helpless here, but this is far from the truth.

Re: Zlib-rs is faster than C

#438

Post by uecker »

nicoburns wrote: post #188
uecker wrote: post #128

Earlier quoted context omitted.

And you think one can not modularize C code and encapsulate critical buffer operations in much safer APIs? One can, the problem is that a lot of legacy C code was not written this way. Also lot of newly written C code is not written this way, but the reason is often that people cut corners when they need to get things done with limited time and resources. The same you will see with Rust.

You're a lot more limited more limited to the kinds of APIs you can safely encapsulate in C. For example, you can't safely encapsulate an interface that shares memory between the library and the caller in C. So you're forced into either: - Exposing an unsafe API and relying on the caller to manually uphold invariants - Doing things like defensive copying at a performance cost In many cases Rust gives you the best of…

Rust is better at this yes, but the practical advantage is not necessarily that huge.

Re: Zlib-rs is faster than C

#439

Post by torginus »

YoshiRulz wrote: post #357
torginus wrote: post #337

Earlier quoted context omitted.

I wonder why writing SIMD in high-level languages hasn't been figured out yet for CPUs (it has been the norm for GPUs for since forever). Auto-vectorization universally sucks, so do OpenMP directives. There was Ispc, which was a separate C-like programming language just for SIMD, but I don't understand why can't regular compilers generated high-quality vectorized code.

.NET (C#) is getting there with Vector .

That's just syntactic sugar (and a bit of architecture independence) over intrinsics. You can get the same in C++ just with wrapping intrinsics in classes, and a few ifdefs.

Re: Zlib-rs is faster than C

#440

Post by no_wizard »

steveklabnik wrote: post #400
no_wizard wrote: post #391

Earlier quoted context omitted.

I don't think we can go beyond the 'human limitations' if you will, of any software. Bugs happen, they're bound to. Its more, what is enforcing the Rust language guarantees and how do we know its enforcing them with reasonably high accuracy one can ascertain? I feel that it can only happen as Rust itself becomes (or perhaps it meaningfully already is) written in pure 100% safe Rust itself. At which point, I believe t…

There is no possible way for something to be written in 100% memory safe code, no matter what the language, if you include "no unsafe code anywhere in the call stack." Interacting with the hardware is not memory safe. Any useful program must on some level involve unsafety. This is true for every programming language.

I wasn't asking for 100%, I am asking for a reasonable proof of assertions.
Post reply on HN