←back to thread

Zlib-rs is faster than C

(trifectatech.org)
341 points dochtman | 3 comments | 16 Mar 25 19:35 UTC | HN request time: 0.473s | source
Show context
johnisgood ◴[16 Mar 25 20:00 UTC] No.43381735[source]▶
"faster than C" almost always boils down to different designs, implementations, algorithms, etc.

Perhaps it is faster than already-existing implementations, sure, but not "faster than C", and it is odd to make such claims.

replies(10): >>43381810 #>>43381813 #>>43381820 #>>43381959 #>>43382108 #>>43382124 #>>43382267 #>>43385171 #>>43386202 #>>43392542 #
kgeist ◴[16 Mar 25 20:42 UTC] No.43382108[source]▶
I heard that aliasing in C prevents the compiler from optimizing aggressively. I can believe Rust's compiler can optimize more aggressively if there's no aliasing problem.
replies(1): >>43382303 #
layer8 ◴[16 Mar 25 21:05 UTC] No.43382303[source]▶
C has the restrict type qualifier to express non-aliasing, hence it shouldn’t be a fundamental impediment.
replies(2): >>43383302 #>>43383607 #
1. gf000 ◴[16 Mar 25 22:48 UTC] No.43383302[source]▶
Which is so underused that the whole compiler feature was buggy as hell, and was only recently fixed because compiling Rust where it is the norm exposed it.
replies(2): >>43383713 #>>43384393 #
2. vacuity ◴[16 Mar 25 23:44 UTC] No.43383713[source]▶
My understanding is that noalias isn't fully utilized by LLVM, just that it's less buggy now, so there's some uncertainty leaning in favor of Rust in terms of future Rust-specific optimizations. Certainly a language like Fortran, with its restrictions, delivers accordingly on optimization, so I imagine Rust has plenty of room to grow similarly.
3. cozzyd ◴[17 Mar 25 01:42 UTC] No.43384393[source]▶
I believe it was mostly an llvm problem and gcc supports restrict fine thanks to Fortran support