Hacker News Reader

Comment by dec0dedab0de | Hacker News Reader

Being written in Rust vs C shouldn't affect speed too much in either direction. It's really the implementation details that matter. The JIT would likely speed things up though as standard CPython does not have a JIT. Though if you're looking for speed with python you're better off with PYPY, mostly because of their JIT which has been in development for a while now.

View on HN

Depends. Nuitka, the Python compiler, takes the python code, translate it to C, then compile it. Not only does it result in a stand alone python program, but it can be up to 4 times faster. Of course, it does compile the python code as well, so it's not just a matter of implementation, but rustpython allows to compile it all to wasm, which, while not binary, is pretty fast.

Sure, but as I see it, both of those are implementation details.

The Standard CPython first compiles to bytecode, then the interpreter translates every instruction as it is ran to the correct instruction for the local platform.

A JIT like this, or PyPy compiles to bytecode, then compiles (some of?) the bytecode to the correct local instructions before running. This means it doesn't need to translate every instruction as it runs.

Projects like Nuitka/Cython compile ahead of time for the platform. So you would either distribute binaries, or have them be compiled at install time.

In any case the only point I was making is that if they made a one to one translation of CPython to RustPython it would not make much of a difference. However, the fact that they are working on a JIT definitely would.

As far as wasm, I beleive it is just building the entire RustPython interpreter as a WASM package. Which I guess would be so you could load it into a browser and then use it to interpret your python code. I suspect this approach would likely be slower than all of the above. Or at the very least be highly dependent on the Browser it is running in.

Another point to consider: the Rust implementation here likely doesn't support any of CPython's old APIs, many of which involve contending the GIL or are otherwise not great for performance. This is all speculation, but that alone might result in some nice performance boosts.

If you're hitting the GIL then yeah, that could be a big win. Though I suspect that the amount people actually hitting the GIL is significantly lower than the amount of people talking about it.

It's been a while since I've written a Python extension, but my understanding is that every single use of `PY_INCREF` or `PY_DECREF` (or any transitive use) hits the GIL, since those reference counts need to be locked.

Almost every Python extension that I've ever read is littered with those calls (macros?), which I'd expect adds up to a decent amount of contention.

You're right, but it's only an issue when the application programmer is using threads. So basically for anyone that is doing CPU intensive work, that can be broken up into chunks, and needs to share memory, and doesn't want to take the time to write their own extension to do that part.

Practically speaking, I/O is usually the bigger bottleneck. Or you can change your algorithm to not share memory, then use multiprocessing, or a task scheduler like celery to spread it over multiple machines.

There are a ton of people who hear about someone running into GIL issues and they think it is affecting them, when they're not doing anything that would be helped by removing it. A JIT compiler on the other hand, would speed up every Python program.

I only talk about the GIL when I try and write some parallel code in Python and get a -10% performance benefit. As a corollary, I only use profanity when speaking of the GIL. But I don't do that often, because I usually skip straight to C++ extensions for code that wants parallelism.

Reply on news.ycombinator.com