6 ms·

I am curious what exactly is the reason GIL hasn't been removed in one of the most popular languages ever?

haney 4y ago
Until now attempts to remove the GIL have come at the cost of reduced single threaded performance. This is the first suggestion that doesn’t degrade single threaded performance.
- kzrdude 4y ago
  Well, all credit to Sam the author, but he "bought" that no degraded performance by adding performance optimizations! Unfortunately, Python 3.11+faster-cpython work has already superseded some of it, i.e negating the trade-in he's trying to accomplish! However, I still hope everyone helps out and that the nogil work can land as default in CPython.
  - coldtea 4y ago
    >Unfortunately, Python 3.11+faster-cpython work has already superseded some of it, i.e negating the trade-in he's trying to accomplish! If "Python 3.11+faster-cpython" didn't also remove the GIL, then it didn't negate anything he's trying to acomplish. He wasn't going for a faster Cpython alone, but for a Cpython without GIL.
  - josefx 4y ago
    > Unfortunately, Python 3.11+faster-cpython work has already superseded some of it, Why is that unfortunate? If his patch being slower than python 3.11 isn't acceptably fast despite being faster than every other python version before that then python was never acceptably fast to begin with. Linux got rid of the BKL ages ago, that the Python community still holds onto the GIL as if it was some multi threading holy grail isn't even remotely funny anymore.
    - kzrdude 4y ago
      It's unfortunate because I think it makes it slightly less likely that his work is accepted, now that part of the sweet single thread performance gains are already supplied from another source.
digisign 4y ago
Popular but historically un/underfunded.
- coldtea 4y ago
  Also: there were lots of independent projects to remove the GIL/speed up Python: from Google, Dropbox, and others. But due to the leadership/community model/aversion to big changes (except for alienating people with 2 to 3 changes) none of this was in the context of CPython, they were independent versions, that never caught on, and didn't leave anything (or much) behind to the regular CPython when they folded.
dagw 4y ago
The first Gil-removal patch I'm aware of was against python 1.4, so it's not like people haven't been trying. The problem has never been removing the GIL per se, but removing the GIL without slowing down the language when running single thread
fulafel 4y ago
You could compile Python using the --without-threads configure option, before Python 3.7 [1] or thereabouts. [1] 3.7.0 is the first major release following the removal of the config option in https://github.com/python/cpython/issues/75551 https://github.com/python/cpython/issues/75551 .. there's also a 2021 comment about "This has unfortunately turned out to be a blocker on getting WASI support as there's not direct threading support in WebAssembly."

Until now attempts to remove the GIL have come at the cost of reduced single threaded performance. This is the first suggestion that doesn’t degrade single threaded performance.

kzrdude 4y ago
Well, all credit to Sam the author, but he "bought" that no degraded performance by adding performance optimizations! Unfortunately, Python 3.11+faster-cpython work has already superseded some of it, i.e negating the trade-in he's trying to accomplish! However, I still hope everyone helps out and that the nogil work can land as default in CPython.
- coldtea 4y ago
  >Unfortunately, Python 3.11+faster-cpython work has already superseded some of it, i.e negating the trade-in he's trying to accomplish! If "Python 3.11+faster-cpython" didn't also remove the GIL, then it didn't negate anything he's trying to acomplish. He wasn't going for a faster Cpython alone, but for a Cpython without GIL.
- josefx 4y ago
  > Unfortunately, Python 3.11+faster-cpython work has already superseded some of it, Why is that unfortunate? If his patch being slower than python 3.11 isn't acceptably fast despite being faster than every other python version before that then python was never acceptably fast to begin with. Linux got rid of the BKL ages ago, that the Python community still holds onto the GIL as if it was some multi threading holy grail isn't even remotely funny anymore.
  - kzrdude 4y ago
    It's unfortunate because I think it makes it slightly less likely that his work is accepted, now that part of the sweet single thread performance gains are already supplied from another source.

digisign 4y ago

Popular but historically un/underfunded.

coldtea 4y ago
Also: there were lots of independent projects to remove the GIL/speed up Python: from Google, Dropbox, and others. But due to the leadership/community model/aversion to big changes (except for alienating people with 2 to 3 changes) none of this was in the context of CPython, they were independent versions, that never caught on, and didn't leave anything (or much) behind to the regular CPython when they folded.

dagw 4y ago

The first Gil-removal patch I'm aware of was against python 1.4, so it's not like people haven't been trying. The problem has never been removing the GIL per se, but removing the GIL without slowing down the language when running single thread

fulafel 4y ago

You could compile Python using the --without-threads configure option, before Python 3.7 [1] or thereabouts. [1] 3.7.0 is the first major release following the removal of the config option in https://github.com/python/cpython/issues/75551 https://github.com/python/cpython/issues/75551 .. there's also a 2021 comment about "This has unfortunately turned out to be a blocker on getting WASI support as there's not direct threading support in WebAssembly."