Hacker News Reader

Comment by throwaway40483 | Hacker News Reader

When I see these rewrites, I'm always left wondering about the speedup achieved. How much was due to:

1) Going from programming language X to Y 2) Rewriting the algorithm in language Y

I suspect (without any proof) that too much is attributed to 1) and not enough to 2).

I'm not sure what this comment is implying. The author isn't complaining about Python's performance, rather, it's noting that concurrency in Python isn't as painless as it is in Rust (which isn't a controversial statement, Rust is explicitly designed for robust concurrency). It also isn't controversial that Rust code should end up faster than Python, considering that Rust is designed to prioritize runtime performance. This isn't a case of comparing the performance of two dynamic languages (as we so often had with all the "I switched to Ruby" or "I switched to Node" posts in prior years); nobody is going to hold up this blog post as proof that Rust is generally faster than Python, because nobody in the world argues otherwise (and I say this as a prolific Python user, not just as a Rust user).

3) Removing "unnecessary cruft" during the rewrite, measuring the speedup and then gradually adding the "cruft" (features) back one by one as previously unknown boundary conditions are encountered.

Restart the process again after a few years of years, as is tradition.

This is not what happened in this case (although I have seen this pattern in other situations in the past). The Rust version is a faithful port of the feature set of the Python version. (It had to be, we were using essentially the entire feature set in production.)

This effect is the reason my default is to be skeptical of benchmarks of new software. It's easy to be fast if you're willing to be incorrect or incomplete.

The article specifically mentions that the program gets invoked over and over again, e.g. by "configure" scripts checking for compiler features.

I don't think anyone would argue that interpreters like CPython have longer startup times than compiled machine code.

At the same time, it's not like there's no way around that. You could make the Python app to keep running and add a super lightweight binary to interface with it. Of course, that may not be worth the trouble.

That's what the python implementation did. Except the lightweight binary to interface with it was also in python. But that still had a massive win, not having to load all the modules every time. I actually rewrote the interfacing binary in rust about two years ago, that would talk to the python server. The python equivalent would start the server if it wasn't already running, but rust, back then, didn't support spawning a subprocess and keeping it alive after the parent process quits, so it was never deployed as a replacement. I filed an issue about that, and iirc, that was fixed, but I never came back to finish and deploy the lightweight rust client. I probably should have.

For the record, I wasn't actually looking for any speedups with this rewrite. Most of it is a straight port of the Python code. The build time speedups were just a nice bonus. (I was measuring just to make sure I didn't regress build times.)

As the author of the original python sccache, I wanted to rewrite it in Rust and expected it would unlock implementing features that would have been hard to implement efficiently in python. I'm glad you beat me to it. Now we can focus on those features :)

Reply on news.ycombinator.com