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

331–340 of 492 posts

Re: Zlib-rs is faster than C

#331

Post by School-Cotton »

gigatexal wrote: post #324
timschmidt wrote: post #36

Earlier quoted context omitted.

Unsafe is a very distinct code smell. Like the hydrogen sulfide added to natural gas to allow folks to smell a gas leak. If you smell it when you're not working on the gas lines, that's a signal.

Someone mentioned to me that for something as simple as a Linked list you have to use unsafe in rust Update its how the std lib does it: https://doc.rust-lang.org/src/alloc/collections/linked_list....

No you don’t. You can use the standard linked list that is already included in the standard library.

Coming up with these niche examples of things you need unsafe for in order to discredit rust’s safety guarantees is just not interesting. What fraction of programmer time is spent writing custom linked lists? Surely way less than 1%. In most of the other 99%, Rust is very helpful.

Re: Zlib-rs is faster than C

#332

Post by FreshOldMage »

fxtentacle wrote: post #308
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…

Yeah, this article about a rust "win" perfectly illustrates why I distrust all good news about it. Rust zlib is faster than zlib-ng, but the latter isn't a particularly fast C contender. Chrome ships a faster C zlib library which Rust could not beat. Rust beat C by using pre-optimized code paths and then C function pointers inside unsafe. Plus C SIMD inside unsafe. I'd summarize the article as: generous chunks of C e…

Did you even read the article? They compare specifically against the Chrome zlib library and beat it at 10 out of 13 chunk sizes considered.

Re: Zlib-rs is faster than C

#333

Post by maccard »

hinkley wrote: post #86
cb321 wrote: post #40

I think this may not be a very high bar. zippy in Nim claims to be about 1.5x to 2.0x faster than zlib: https://github.com/guzba/zippy I think there are also faster zlib's around in C than the standard install one, such as https://github.com/ebiggers/libdeflate (EDIT: also mentioned elsethread https://news.ycombinator.com/item?id=43381768 by mananaysiempre) zlib itself seems pretty antiquated/outdated these days, but…

Zlib is unapologetically written to be portable rather than fast. It is absolutely no wonder that a Rust implementation would be faster. It runs on a pathetically small number of systems by contrast. This is not a dig at Rust, it’s an acknowledgement of how many systems exist out there, once you include embedded, automotive, aerospace, telecom, industrial control systems, and mainframes. Richard Hipp denounces claims…

Except this comparison isn’t against zlib, it’s against zlib-ng [0]. The readme states:

> The result is a better performing and easier to maintain zlib-ng.

So they’re comparing a first pass rewrite against a variation of zlib designed for performance

[0] https://github.com/zlib-ng/zlib-ng

Re: Zlib-rs is faster than C

#334

Post by School-Cotton »

johnisgood wrote: post #322
TheDong wrote: post #296

Earlier quoted context omitted.

Such a rust zealot is a strawman, though please don't let me stop you from enjoying burning such a strawman.

How is it a strawman? Many people have misconceptions with regarding to Rust, while not even knowing about the existence of Ada/SPARK to begin with. They blindly spout "Rust is saFeEe!44!". If you are not a zealot, then it is not applied to you.

I see about 1000x more anti-rust-zealot strawman arguments than rust zealots on this site. Can you give some examples of the misguided rust zealotry you’re talking about?

Re: Zlib-rs is faster than C

#335

Post by cb321 »

renewiltord wrote: post #159
vkou wrote: post #78

Earlier quoted context omitted.

I think you'll find that if you re-write an application, feature-for-feature, without changing its language, the re-written version will be faster.

This is known as the Second System Effect: where Great Rewrites always succeed in making a more performant thing.

I am not sure if the semantics have drifted over the decades to what you say, but this seems not quite right according to wikipedia: https://en.wikipedia.org/wiki/Second-system_effect

EDIT: but I do agree that starting greenfield from an old code base is often a path towards performance.

Re: Zlib-rs is faster than C

#336

Post by andai »

serial_dev wrote: post #311
Someone wrote: post #298

Earlier quoted context omitted.

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 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 surprise with number crunching, with C# and C++. I wrote the same program (rational approximation of Pi), line for line, in both languages, and the C# version ran faster. Apparently C# aggressively optimizes hot code paths while running, whereas to get that behavior in C++, you need to collect profiler data and use a special compiler flag.

Re: Zlib-rs is faster than C

#337

Post by torginus »

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…

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.

Re: Zlib-rs is faster than C

#338

Post by chjj »

pdimitar wrote: post #318
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.

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?

[flagged]

Re: Zlib-rs is faster than C

#339

Post by [deleted] »

School-Cotton wrote: post #334
johnisgood wrote: post #322

Earlier quoted context omitted.

How is it a strawman? Many people have misconceptions with regarding to Rust, while not even knowing about the existence of Ada/SPARK to begin with. They blindly spout "Rust is saFeEe!44!". If you are not a zealot, then it is not applied to you.

I see about 1000x more anti-rust-zealot strawman arguments than rust zealots on this site. Can you give some examples of the misguided rust zealotry you’re talking about?

[deleted]

Re: Zlib-rs is faster than C

#340

Post by Boereck »

brianpane wrote: post #326

I contributed a number of performance patches to this release of zlib-rs. This was my first time doing perf work on a Rust project, so here are some things I learned: Even in a project that uses `unsafe` for SIMD and internal buffers, Rust still provided guardrails that made it easier to iterate on optimizations. Abstraction boundaries helped here: a common idiom in the codebase is to cast a raw buffer to a Rust slic…

Interesting! I wonder if you have used PGO in the project? Forcing fields to be located next to each other kind of feels like something that PGO could do for you.
Post reply on HN