←back to thread

Zlib-rs is faster than C

(trifectatech.org)
341 points dochtman | 1 comments | | HN request time: 0.199s | source
Show context
johnisgood ◴[] 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 #
tdiff ◴[] No.43381959[source]
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
replies(2): >>43382117 #>>43386236 #
pinkmuffinere ◴[] No.43382117[source]
I’m sure I’m missing context, and presumably there are other benefits, but 5-15% improvement is such a small step to justify rewriting codebases.

I also wonder how much of an improvement you’d get by just asking for a “simple rewrite” in the existing language. I suspect there are often performance improvements to be had with simple changes in the existing language

replies(5): >>43382207 #>>43382269 #>>43382320 #>>43383954 #>>43385793 #
turtletontine ◴[] No.43382269[source]
Far better justification for a rewrite like this is if it eases maintenance, or simplifies building/testing/distribution. Taking an experienced and committed team of C developers with a mature code base, and retraining them to rewrite their project in Rust for its own sake is pretty absurd. But if you have a team that’s more comfortable in Rust, then doing so could make a lot of sense - and, yes, make it easier to ensure the product is secure and memory-safe.
replies(2): >>43382335 #>>43386853 #
1. johnisgood ◴[] No.43382335[source]
> if you have a team that’s more comfortable in

As is the case with any languages, of course, it is not in favor (nor against) Rust.