by dochtman on 3/16/25, 7:35 PM with 473 comments
by brianpane on 3/17/25, 10:06 AM
by YZF on 3/16/25, 8:12 PM
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 mattering if this is C or Rust?Presumably with inline assembly both languages can emit what is effectively the same machine code. Is the Rust compiler a better optimizing compiler than C compilers?
by johnisgood on 3/16/25, 8:00 PM
Perhaps it is faster than already-existing implementations, sure, but not "faster than C", and it is odd to make such claims.
by cb321 on 3/16/25, 8:32 PM
zlib itself seems pretty antiquated/outdated these days, but it does remain popular, even as a basis for newer parallel-friendly formats such as https://www.htslib.org/doc/bgzip.html
by jrockway on 3/16/25, 8:47 PM
Some reading: https://jolynch.github.io/posts/use_fast_data_algorithms/
(As an aside, at my last job container pushes / pulls were in the development critical path for a lot of workflows. It turns out that sha256 and gzip are responsible for a lot of the time spent during container startup. Fortunately, Zstandard is allowed, and blake3 digests will be allowed soon.)
by IshKebab on 3/16/25, 7:55 PM
by 1vuio0pswjnm7 on 3/17/25, 3:05 AM
Which library has fewer dependencies.
Is each library the same size. Which one is smaller.
by miki123211 on 3/17/25, 6:16 PM
If you're writing your program in C, you're afraid of shooting yourself in the foot and introducing security vulnerabilities, so you'll naturally tend to avoid significant refactorings or complicated multithreading unless necessary. If you have Rust's memory safety guarantees, Go's channels and lightweight goroutines, or the access to a test runner from either of those languages, that's suddenly a lot less of a problem.
The compiler guarantees you get won't hurt either. Just to give a simple example, if your Rust function receives an immutable reference to a struct, it can rely on the fact that a member of that struct won't magically be mutated by a call to some random function through spooky action at a distance. It can just keep it on the stack / in a callee-saved register instead of fetching it from memory at every loop iteration, if that's more optimal.
Then there's the easy access to package ecosystems and extensive standard libraries. If there's a super popular do_foo package, you can almost guarantee that it was a bottleneck for somebody at some point, so it's probably optimized to hell and back. It's certainly more optimized than your simple 10-line do_foo function that you would have written in C, because that's easier than dealing with yet another third-party library and whatever build system it uses.
by throwaway2037 on 3/17/25, 3:54 AM
by up2isomorphism on 3/17/25, 5:31 AM
by Georgelemental on 3/17/25, 7:22 PM
Rust very much can emulate this, with `break` + nested blocks. But not if you also add in `goto` to previous branches
by CyberDildonics on 3/16/25, 11:49 PM
An optimized version that controls allocations, has good memory access patterns, uses SIMD and uses multi-threading can easily be 100x faster or more. Better memory access alone can speed a program up 20x or more.
by quotemstr on 3/17/25, 9:15 AM
by randomNumber7 on 3/17/25, 9:35 PM
by kahlonel on 3/16/25, 8:04 PM
by akagusu on 3/16/25, 10:37 PM