Removing GIL naively would decrease single thread performance. Every project aiming at removing GIL failed because it could not get performance comparable with GILed Python.
It's a fork of Python 3.9, takes out GIL and introduces optimisations to speed up both single- and multi-threaded execution (since the bar set by PSF is that no-GIL implementations must be at least as fast as GIL single threaded programs). He ends up with a net 10% speed improvement.
If he does these optimisations, and also doesn't remove the GIL, the performance boost is even larger. So, depending on how you look at it, it's either:
- A bunch of optimisations, plus a GILectomy which slows Python down, or
- A bulk change that removes GIL and speeds things up
Since these improvements were in a similar ballpark, my fear was that the improvements are taken off the branch, with GIL left in place...
Tracing GC does not run into this problem. Why Python doesn't use tracing GC is not something I am qualified to answer.
Sam Gross' work: https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsD...
The GIL code: https://github.com/python/cpython/blob/main/Python/ceval_gil...
Py_INCREF: https://github.com/python/cpython/blob/a4460f2eb8b9db46a9bce...