Brett CannonJan 23, 2023
Let's say CPython can gain a JIT or get rid of the GIL, but not both. Which would you want to have more?
JIT
51%
No GIL
49%
Poll ended at .
Show threadTamir BaharJan 23, 2023

@brettcannon Not quite sure where I lean on this.

On the one hand - no GIL would be great. It really hurts to run single-core on multi-core machines.
On the other hand - I'm pretty sure we'll have to rewrite most existing libraries to be properly thread-safe, and I don't think anyone wants that. I mean - how do you even go about it? Add "no GIL" as a specifier for packages?

JIT is tricky as well. Can `inspect` keep working as it is? Will we have to give things up? How do we manage that?

Show threadBrett CannonJan 24, 2023

@tmr232 https://peps.python.org/pep-0703/ for the no-GIL details, but yes, packages would need "GIL" and "no GIL" wheels.

As for the JIT, why do you think 'inspect' would stop working when the source code had to be there to JIT to begin with?

PEP 703 – Making the Global Interpreter Lock Optional in CPython | peps.python.org

CPython’s global interpreter lock (“GIL”) prevents multiple threads from executing Python code at the same time. The GIL is an obstacle to using multi-core CPUs from Python efficiently. This PEP proposes adding a build configuration (--disable-gil) to...

Python Enhancement Proposals (PEPs)
Show threadTamir Bahar
@brettcannon Python already compromises performance to ensure all stack frames are present and look the way they should.
If we add JIT, we'll still need to ensure all variables & stack frames are properly populated. A bit like a debug build.
I assume that this will result in significant performance loss compared to a version without those guarantees.
Jan 24, 2023 at 7:20pmElk
Show threadBrett CannonJan 24, 2023
@tmr232 I trust the Faster CPython team to know what they are doing if/when they tackle a JIT (I know they are contemplating it).