5 ms·

Your phrasing makes it sound like the GIL is a net-negative, and thats just false. There is a tiny subset of applications that would benefit from its removal, e

by y4mi 5y ago

Your phrasing makes it sound like the GIL is a net-negative, and thats just false. There is a tiny subset of applications that would benefit from its removal, everyone else would have their performance reduced by ~40% (last attempt to remove it ended with a 40% performance penalty). the project is generally open to PR to remove it as long as the performance doesn't suffer. and i'll be honest: if you're writing code thats so performance critical that you're worrying about the GIL... why the hell do you use python in the first place? use at least a compiled language.

chc 5y ago
There's a big difference between "the GIL is net neutral or positive in terms of performance" and "removing the GIL from Python after 30 years of having it baked in is pretty hard to do cleanly." What you're observing here appears to be the latter. If lacking a GIL actually incurred a 40% performance penalty in general and not as a consequence of design decisions in Python's internals, we'd expect to see the fastest languages all sporting GILs, and that is really not the case.
- upbeat_general 5y ago
  It’s unclear what you mean by design decisions of python’s internals. Certainly python could have instead been a compiled language but then it’d be fundamentally different language. Are you implying that all of Pythons features could be preserved without a GIL and no performance loss if say a full rewrite was possible?
  - ynik 5y ago
    I don't think it's possible without breaking changes. But if we're willing to accept some changes to the C API, it's at least possible to make the GIL less global. It really should be obvious that it's possible to have multiple Python interpreters in the same process, where multiple independent threads run Python code in parallel, with occasional calls into a shared data structure implemented as a multi-threaded C extension module. Currently the GIL makes this impossible: you either can have the multi-threaded C extension module in a single process (but then the Python threads will be limited by Amdahl's law unless you spend >99.9% of CPU time inside the extension module), or you can use multiprocessing which lets the Python code run in parallel, but than the C extension module will have to figure out how to use shared memory. This is a massive, massive problem for us. We're already invested almost a year of developer time into changing C++ libraries to tell all those pesky std::strings to allocate their data in a shared memory segment. Even then, we've only managed this for some of our shared data structured so far, so this only allows us to parallelize around half of our Python stuff. So in effect, the GIL is causing massive extra complexity for us, and still prevents us from using more than ~2 CPU cores. We would have been massively better off if 15 years ago we picked Javascript instead of Python. JS is also "single-threaded" like Python, but the JS interpreter lock is much less of a problem because it's not global. Now Python currently has a "sub-interpreter" effort underway that refactors the interpreter to avoid all that global state and make it per-interpreter. But I somehow doubt that this approach to remove the GIL will be accepted, because again, it will slow down single-threaded execution: e.g. obtaining the `PyObject*` of `None` is currently simply taking the adress of the `_Py_None` global variable. Python will need to split this into one `None` object per interpreter, because (like any Python object) None has a reference count that is mutated all the time. But existing extension modules are accessing the `Py_None` macro -- they don't provide any context which interpreter's `None` they want! This can be solved with some TLS lookups ("what interpreter is the current thread working with"), but I suspect that will be enough of a slowdown that the whole approach will be rejected (since "no performance loss for single-threaded code" seems to be a requirement). I think Python will get rid of the GIL eventually, but it will take a Python 4.0 with a bunch of breaking changes for C extensions to do so without significant performance loss.
  - johncolanduoni 5y ago
    This has already been done, it’s called PyPy[1]. It both does not have a process-wide GIL and is faster than CPython almost across the board. [1]: https://www.pypy.org/ https://www.pypy.org/
    - seunosewa 5y ago
      PyPy has a GIL: 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...
deleted 5y ago
[deleted]
cdogl 5y ago
If your claim is true - that removing the GIL would harm the vast majority of programs - that speaks to some deep-seated quality and architecture issues in CPython. I happen to agree. I love Python, but the limits of its implementation sent me packing to Go years ago and I haven't looked back.
- wiredfool 5y ago
  The problem is not python programs, it's existing C language extensions. Removing the GIL while retaining compatibility with the extensions and single threaded performance is difficult.
- lmm 5y ago
  It speaks to some deep-seated tradeoffs in CPython. I don't know that reference-counting or using the C stack were the right choices, but Python's existence as approximately the only sane language where you can count on every library being available suggests that they're doing something right.
qsi 5y ago
> and i'll be honest: if you're writing code thats so performance critical that you're worrying about the GIL... why the hell do you use python in the first place? use at least a compiled language. Fair enough, but sometimes your freedom of choice may be limited. We have a large push for Python at our org, and for most people that's probably fine (or even really good), but I'm holding out as long as I can with Matlab and Julia.
AtlasBarfed 5y ago
Right, basically the GIL is a ceiling on what-you-can-do with python. Python has now passed Java in TIOBE, which means it has a HUGE number of people using it. That represents a tremendous amount of collective investment and work in that ecosystem. C/C++ obviously provides nigh-unbounded access to the hardware for doing "serious stuff" like databases, high performance IO/big data/etc. Java has pretty-darn-good abilities to do "serious stuff" with its threading models and optimizing JVM. But Python is basically capped by the GIL. So while the amount of code written in Python (and Javascript I'd argue) is massive... does any of it substantively push forward the state of the art? Will layers of the OS improve? Will new databases or cache layers or large scale data processing be improved/advanced? We're basically at the end of Ghz scaling, it's all increasing wafer sizes and transistor counts ... lots of processors. LOTS of processors. If the #2 software language in TIOBE can't fundamentally properly use the hardware that the next decade will be running on outside of a core or two... that's a problem. All our devices have been sidestepping this at the consumer level with two or four cores for the last decade, while server counts have been expanding. Four cores can ignored at the application level because other cores can do OS maintenance tasks, UI rendering tasks, etc etc etc. But if your 2025 consumer device has 12-32 cores, and your software can only run on one of them... and it's the #2 programming language, and the reason is the GIL and it's baked so deeply and perniciously into your entire software ecosystem... Then to your point, why the hell will people use python? And then it will tumble to irrelevance.

by y4mi 5y ago

chc 5y ago

There's a big difference between "the GIL is net neutral or positive in terms of performance" and "removing the GIL from Python after 30 years of having it baked in is pretty hard to do cleanly." What you're observing here appears to be the latter. If lacking a GIL actually incurred a 40% performance penalty in general and not as a consequence of design decisions in Python's internals, we'd expect to see the fastest languages all sporting GILs, and that is really not the case.

upbeat_general 5y ago
It’s unclear what you mean by design decisions of python’s internals. Certainly python could have instead been a compiled language but then it’d be fundamentally different language. Are you implying that all of Pythons features could be preserved without a GIL and no performance loss if say a full rewrite was possible?
- ynik 5y ago
  I don't think it's possible without breaking changes. But if we're willing to accept some changes to the C API, it's at least possible to make the GIL less global. It really should be obvious that it's possible to have multiple Python interpreters in the same process, where multiple independent threads run Python code in parallel, with occasional calls into a shared data structure implemented as a multi-threaded C extension module. Currently the GIL makes this impossible: you either can have the multi-threaded C extension module in a single process (but then the Python threads will be limited by Amdahl's law unless you spend >99.9% of CPU time inside the extension module), or you can use multiprocessing which lets the Python code run in parallel, but than the C extension module will have to figure out how to use shared memory. This is a massive, massive problem for us. We're already invested almost a year of developer time into changing C++ libraries to tell all those pesky std::strings to allocate their data in a shared memory segment. Even then, we've only managed this for some of our shared data structured so far, so this only allows us to parallelize around half of our Python stuff. So in effect, the GIL is causing massive extra complexity for us, and still prevents us from using more than ~2 CPU cores. We would have been massively better off if 15 years ago we picked Javascript instead of Python. JS is also "single-threaded" like Python, but the JS interpreter lock is much less of a problem because it's not global. Now Python currently has a "sub-interpreter" effort underway that refactors the interpreter to avoid all that global state and make it per-interpreter. But I somehow doubt that this approach to remove the GIL will be accepted, because again, it will slow down single-threaded execution: e.g. obtaining the `PyObject*` of `None` is currently simply taking the adress of the `_Py_None` global variable. Python will need to split this into one `None` object per interpreter, because (like any Python object) None has a reference count that is mutated all the time. But existing extension modules are accessing the `Py_None` macro -- they don't provide any context which interpreter's `None` they want! This can be solved with some TLS lookups ("what interpreter is the current thread working with"), but I suspect that will be enough of a slowdown that the whole approach will be rejected (since "no performance loss for single-threaded code" seems to be a requirement). I think Python will get rid of the GIL eventually, but it will take a Python 4.0 with a bunch of breaking changes for C extensions to do so without significant performance loss.
- johncolanduoni 5y ago
  This has already been done, it’s called PyPy[1]. It both does not have a process-wide GIL and is faster than CPython almost across the board. [1]: https://www.pypy.org/ https://www.pypy.org/
  - seunosewa 5y ago
    PyPy has a GIL: 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...

deleted 5y ago

[deleted]

cdogl 5y ago

If your claim is true - that removing the GIL would harm the vast majority of programs - that speaks to some deep-seated quality and architecture issues in CPython. I happen to agree. I love Python, but the limits of its implementation sent me packing to Go years ago and I haven't looked back.

wiredfool 5y ago
The problem is not python programs, it's existing C language extensions. Removing the GIL while retaining compatibility with the extensions and single threaded performance is difficult.
lmm 5y ago
It speaks to some deep-seated tradeoffs in CPython. I don't know that reference-counting or using the C stack were the right choices, but Python's existence as approximately the only sane language where you can count on every library being available suggests that they're doing something right.

qsi 5y ago

> and i'll be honest: if you're writing code thats so performance critical that you're worrying about the GIL... why the hell do you use python in the first place? use at least a compiled language. Fair enough, but sometimes your freedom of choice may be limited. We have a large push for Python at our org, and for most people that's probably fine (or even really good), but I'm holding out as long as I can with Matlab and Julia.

AtlasBarfed 5y ago

Right, basically the GIL is a ceiling on what-you-can-do with python. Python has now passed Java in TIOBE, which means it has a HUGE number of people using it. That represents a tremendous amount of collective investment and work in that ecosystem. C/C++ obviously provides nigh-unbounded access to the hardware for doing "serious stuff" like databases, high performance IO/big data/etc. Java has pretty-darn-good abilities to do "serious stuff" with its threading models and optimizing JVM. But Python is basically capped by the GIL. So while the amount of code written in Python (and Javascript I'd argue) is massive... does any of it substantively push forward the state of the art? Will layers of the OS improve? Will new databases or cache layers or large scale data processing be improved/advanced? We're basically at the end of Ghz scaling, it's all increasing wafer sizes and transistor counts ... lots of processors. LOTS of processors. If the #2 software language in TIOBE can't fundamentally properly use the hardware that the next decade will be running on outside of a core or two... that's a problem. All our devices have been sidestepping this at the consumer level with two or four cores for the last decade, while server counts have been expanding. Four cores can ignored at the application level because other cores can do OS maintenance tasks, UI rendering tasks, etc etc etc. But if your 2025 consumer device has 12-32 cores, and your software can only run on one of them... and it's the #2 programming language, and the reason is the GIL and it's baked so deeply and perniciously into your entire software ecosystem... Then to your point, why the hell will people use python? And then it will tumble to irrelevance.