3 ms·

Is it at all possible to make Python really fast given that it depends on GIL, that to my understanding makes Python performance memory bound?

hodwik 11y ago
Could you explain why GIL wouldn't make it CPU bound, rather than memory bound?
- eveningcoffee 11y ago
  I am sorry, but by memory I meant cache memory that is in fact inside the CPU. This is error on my side. I read [0] and could not infer anything to confirm my understanding, but if we consider the semantics of GIL, then there should be some form of guarantee in place that two CPU cores see the coherent picture of the cache (other way two threads would see incoherent values of the same variable or would not see the changes at all). This is usually archived by some form of memory barriers and flushing the registers into memory and this by my experience (that comes from Java) makes the code order of magnitude or two slower. [0] https://wiki.python.org/moin/GlobalInterpreterLock https://wiki.python.org/moin/GlobalInterpreterLock
andreasvc 11y ago
The GIL is an issue when you want parallelism. It is not relevant when talking about single thread performance.
- eveningcoffee 11y ago
  As I understand it, it eliminates some optimization possibilities and adds overhead. I do not have time to check the Python code to see how it is actually implemented (hence my question) but based on my knowledge it would imply at least a CAS operation to check and take the lock, writing the register values into memory (cache) and applying a memory barrier. You can not keep the values in the registries (elimination of optimization possibilities) and you add considerable overhead by needing memory barriers and CAS operations. I am not claiming that Python does it like this, I am just assuming that it should do it like this to obtain the guaranties of GIL.
  - smegel 11y ago
    The GIL is a condition variable and a mutex. Nothing fancy. In a single threaded program, it gets acquired once, if at all.
    - eveningcoffee 11y ago
      Mutex and a shared condition variable are expensive compared to the single instruction. But I had an impression that it is acquired before every atomic Python instruction and it looks that it is actually acquired for group of predefined number of instructions (100) that then are executed inside one GIL time frame [0]. Therefore it actually should not be a big obstacle to make Python code run fast by a JIT compiler. [0] http://www.dabeaz.com/python/GIL.pdf http://www.dabeaz.com/python/GIL.pdf

hodwik 11y ago

Could you explain why GIL wouldn't make it CPU bound, rather than memory bound?

eveningcoffee 11y ago
I am sorry, but by memory I meant cache memory that is in fact inside the CPU. This is error on my side. I read [0] and could not infer anything to confirm my understanding, but if we consider the semantics of GIL, then there should be some form of guarantee in place that two CPU cores see the coherent picture of the cache (other way two threads would see incoherent values of the same variable or would not see the changes at all). This is usually archived by some form of memory barriers and flushing the registers into memory and this by my experience (that comes from Java) makes the code order of magnitude or two slower. [0] https://wiki.python.org/moin/GlobalInterpreterLock https://wiki.python.org/moin/GlobalInterpreterLock

andreasvc 11y ago

The GIL is an issue when you want parallelism. It is not relevant when talking about single thread performance.

eveningcoffee 11y ago
As I understand it, it eliminates some optimization possibilities and adds overhead. I do not have time to check the Python code to see how it is actually implemented (hence my question) but based on my knowledge it would imply at least a CAS operation to check and take the lock, writing the register values into memory (cache) and applying a memory barrier. You can not keep the values in the registries (elimination of optimization possibilities) and you add considerable overhead by needing memory barriers and CAS operations. I am not claiming that Python does it like this, I am just assuming that it should do it like this to obtain the guaranties of GIL.
- smegel 11y ago
  The GIL is a condition variable and a mutex. Nothing fancy. In a single threaded program, it gets acquired once, if at all.
  - eveningcoffee 11y ago
    Mutex and a shared condition variable are expensive compared to the single instruction. But I had an impression that it is acquired before every atomic Python instruction and it looks that it is actually acquired for group of predefined number of instructions (100) that then are executed inside one GIL time frame [0]. Therefore it actually should not be a big obstacle to make Python code run fast by a JIT compiler. [0] http://www.dabeaz.com/python/GIL.pdf http://www.dabeaz.com/python/GIL.pdf