ideas VS nogil

Lower latency native calls in Python would be extremely useful, thank you for your work! Is the following GitHub issue the right place to monitor progress? https://github.com/faster-cpython/ideas/issues/546

I'm open to doing some benchmarking. Several of my libraries have pure CPython bindings (StringZilla, UCall, SimSIMD), and all perform low-latency SIMD-accelerated ops, so might be a good testing ground :)

Recent CPython development has been towards optimizations and addressing use cases that benefit from optimizations, some coming from the faster CPython initiative. You might just get your JIT[1].

[1] https://github.com/faster-cpython/ideas/wiki/Workflow-for-3....

The faster-cpython folks seem to be working towards a JIT (https://github.com/faster-cpython/ideas/tree/main/3.13) and both pyston and cinder have JITs. So I don't think anyone has ruled one out.

faster-cpython team has done a lot of work to experiment on it: https://github.com/faster-cpython/ideas/issues/485#issuecomm...

It kind of sounds like migration to register based is a foregone conclusion, but it's not very clear to me.

lots of big ideas are still remaining to be done. One example is the register based interpreter, see https://github.com/faster-cpython/ideas/issues/485

A previous plan called for the beginning of a JIT in 3.12, seen as "Trace optimized interpreter" here: https://github.com/faster-cpython/ideas/wiki/Workflow-for-3....

This might be a dumb question, but why would removing the GIL break FFI? Is it just that existing no-GIL implementations/proposals have discarded/ignored it, or is there a fundamental requirement, e.g. C programs unavoidably interact directly with the GIL? I know that the C-API is only stable between minor releases [0] compiled in the same manner [1], so it's not like the ecosystem is dependent upon it never changing.

I cannot seem to find much discussion about this. I have found a no-GIL interpreter that works with numpy, scikit, etc. [2][3] so it doesn't seem to be a hard limit. (That said, it was not stated if that particular no-GIL implementation requires specially built versions of C-API libs or if it's a drop-in replacement.)

[0]: https://docs.python.org/3/c-api/stable.html#c-api-stability

[1]: https://docs.python.org/3/c-api/stable.html#platform-conside...

[2]: https://github.com/colesbury/nogil

[3]: https://discuss.python.org/t/pep-703-making-the-global-inter...

https://github.com/colesbury/nogil does manage to get rid of the GIL, but it's not certain to make it into Python core. The main problem is the amount of existing libraries that depend on the existence of the GIL without realizing it - breaking those would be extremely disruptive.

CPython is also investigating the removal of the GIL (PEP703, nogil). I think requiring the GIL is a wider thing that libraries will need to address anyway. But also, for the same reason as above I'd be surprised if the Modular team thought that saying "you can run all your python code unchanged" was a good idea if there was a secret "except for code that uses numpy" muttered under the breath.

I'm worried about the speedup

My understanding is that it's based on the most recent attempt to remove the GIL by Sam Gross

https://github.com/colesbury/nogil

In addition to some ways to try to not have nogil have as much overhead he added a lot of unrelated speed improvements so that python without the gil would still be faster not slower in single thread mode. They seem to have merged those performance patches first that means if they add his Gil removal patches in say python 3.12 it will still be substantially slower then 3.11 although faster then 3.10. I hope that doesn't stop them from removing the gil (at least by default)

Looks like it's still active to me:

https://github.com/colesbury/nogil/