3 ms·

>> So basically a JIT would help every Python program, and removing the GIL would only help a small subset of Python programs. What if the "Global Interpreter

>> So basically a JIT would help every Python program, and removing the GIL would only help a small subset of Python programs. What if the "Global Interpreter Lock" needs to be removed for JIT? I put that in quotes to highlight it because AFAICT no compiled (or JITed) language has such a thing. I think it functions differently than regular stuff like critical sections.

dec0dedab0de 5y ago
What if the "Global Interpreter Lock" needs to be removed for JIT? It doesn't. PyPy has a JIT and a GIL. The JIT just compiles the byte code to native code before running, along with some tricks that are over my head. Edit: Here is PyPy's FAQ about it https://doc.pypy.org/en/latest/faq.html#does-pypy-have-a-gil-why https://doc.pypy.org/en/latest/faq.html#does-pypy-have-a-gil...
heavyset_go 5y ago
Last time I looked, Ruby had a GIL and JIT.
native_samples 5y ago
High performance JIT compiling VMs don't use a GIL, they use a different trick called safe points. The compiled code polls a global or per-thread variable as it runs (but in a very optimized way). When one thread tries to change something that might break another thread, the other threads are brought to a clean halt at specific points in the program where the full state of the abstract interpreter can be reconstructed from the stack and register state. Then the thread stacks are rewritten to force the thread back into the interpreter and the compiled code is deallocated. The result is that if you need to change something that is in practice only changed very rarely, instead of constantly locking/unlocking a global lock (very, very slow) you replace it with a polling operation (can be very fast as the CPU will execute it speculatively). However, this requires a lot of very sophisticated low level virtual machinery. The JVM has it. V8 has it. CLR has a limited form of it. Maybe PyPy does, I'm not sure? Most other runtimes do not. For the Python community, very likely the best way to upgrade performance would be to start treating CPython as stable/legacy, then support and encourage efforts like GraalPython. That way the community can re-use all the effort put into the JVM.
- xorcist 5y ago
  PyPy can utilitize something called software transactional memory to the same effect. This gives you a unusually fast Python that is also GIL-less. It doesn't seem to be used much, so there may be some compatibility problems or similar, but for a trivial test it worked just as described many years ago. It also tells me that the GIL isn't terribly important for most things Python is used for. It certainly isn't for me.

dec0dedab0de 5y ago

What if the "Global Interpreter Lock" needs to be removed for JIT? It doesn't. PyPy has a JIT and a GIL. The JIT just compiles the byte code to native code before running, along with some tricks that are over my head. Edit: Here is PyPy's FAQ about it https://doc.pypy.org/en/latest/faq.html#does-pypy-have-a-gil-why https://doc.pypy.org/en/latest/faq.html#does-pypy-have-a-gil...

heavyset_go 5y ago

Last time I looked, Ruby had a GIL and JIT.

native_samples 5y ago

High performance JIT compiling VMs don't use a GIL, they use a different trick called safe points. The compiled code polls a global or per-thread variable as it runs (but in a very optimized way). When one thread tries to change something that might break another thread, the other threads are brought to a clean halt at specific points in the program where the full state of the abstract interpreter can be reconstructed from the stack and register state. Then the thread stacks are rewritten to force the thread back into the interpreter and the compiled code is deallocated. The result is that if you need to change something that is in practice only changed very rarely, instead of constantly locking/unlocking a global lock (very, very slow) you replace it with a polling operation (can be very fast as the CPU will execute it speculatively). However, this requires a lot of very sophisticated low level virtual machinery. The JVM has it. V8 has it. CLR has a limited form of it. Maybe PyPy does, I'm not sure? Most other runtimes do not. For the Python community, very likely the best way to upgrade performance would be to start treating CPython as stable/legacy, then support and encourage efforts like GraalPython. That way the community can re-use all the effort put into the JVM.

xorcist 5y ago
PyPy can utilitize something called software transactional memory to the same effect. This gives you a unusually fast Python that is also GIL-less. It doesn't seem to be used much, so there may be some compatibility problems or similar, but for a trivial test it worked just as described many years ago. It also tells me that the GIL isn't terribly important for most things Python is used for. It certainly isn't for me.