The first year of free-threaded Python

20 points by ngoldbaum

zipy124

On one hand I love performance increases, but on the other hand, if you want fast code it’s better to use Python as glue to call out to faster libraries via FFI which can already utilise the advantages of no GIL. When using Numpy or OpenCV functions for example most are not written in python and are already multi-threaded/process.

Since Python by most benchmarks is somewhere around 2 order of magnitudes slower than comparable compiled languages, even a 20x speed up on a 20 core machine is futile compared to re-writing it in a single-threaded compiled language. Not even considering that you can get that same speed up in your compiled language often with as little as one line of code using OpenMP in c++ or Julia for exaple.

In general if you want python and you want performance, It’s better to use Python for doing all the light work, and then calling to faster compiled code for anything performance critical. This allows you to get the best of both worlds in terms of speed and productivity and leveraging the ecosystem and batteries included std lib.

cdown
Python isn’t an ideal production language for many reasons (and I would discourage its use for any new production application), but the changes are still valuable for places where it is already extant. In many cases there are already large, working codebases in Python for which the business case to write it in something else is very low. For example, cases where all the developers employed already understand Python, and the risks of conversion to something else are very high. For example, we probably wouldn’t write Instagram in Python today, but the likelihood that we would rewrite it from the ground up in another language is very low due to many factors. As such we instead have invested in:
1. Other tooling, like building Cinder (which had a no GIL mode for a long time, and was the team that funded a lot of this work upstream).
2. Extracting particularly costly operations as services which can then be written in (for example) C++ or Rust and called separately. Usually these are written by different people than those implementing the user-facing logic.
On medium to small codebases it may make sense to have instead rewritten the project, but in this case, it’s vastly cheaper to try to improve CPython.