4 ms·

Every single HN thread on python performance, ever: Person with limited to zero experience with CPython internals> I hate the GIL, why don't they just remove i

by kortex 3y ago

Every single HN thread on python performance, ever: Person with limited to zero experience with CPython internals> I hate the GIL, why don't they just remove it? That just is doing an incredible amount of heavy lifting. It'd be like saying, "Why doesn't the USA just switch entirely to the metric system?" It's a huge ask, and after being burned by the 2/3 transition, the python team is loathe to rock to boat too much again. The GIL is deep, arguably one of the deepest abstractions in the codebase, up there with PyObject itself. Think about having to redefine the String implementation of a codebase in your language of choice. Whatever your monday-morning quarterback idea on how to pull out the GIL is, I can almost guarantee, someone has thought about it, probably implemented it, and determined it will have one or more side effects: - Reduced single-thread performance - Breaking ABI/FFI compatibility - Not breaking ABI immediately, but massively introducing the risk of hard to track concurrency bugs that didn't exist before, because GIL - Creating a maintenance nightmare by adding tons of complexity, switches, conditionals, etc to the codebase The team has already decided those tradeoffs are not really justifiable. The GILectomy project has probably come the closest, but it impacts single-thread performance by introducing a mutex (there are some reference type tricks [1] to mitigate the hit, but it still hurts run time 10-50%), and necessitates any extension libraries update their code in a strongly API-breaking way. It's possible that over time, there are improvements which simultaneously improve performance or maintainability, while also lessening the pain of a future GILectomy, e.g. anything which reduces the reliance on checking reference counts. [1] PEP 683 is probably a prerequisite for any future GILectomy attempts, which looks like it has been accepted, which is great https://peps.python.org/pep-0683/ https://peps.python.org/pep-0683/

arp242 3y ago
There were already patches to "just" remove the GIL for Python 2.0 or thereabouts, over 20 years ago. Strictly technically speaking it's not even that hard, but as you mentioned it comes with all sorts of trade-offs. Today Python is one of the world's most popular programming language, if not the most popular language. The GIL is limiting and a trade-off in itself of course – designing any programming language is an exercise in trade-offs. But clearly Python has gotten quite far with the set of trade-offs it has chosen: you need to be careful to "just" radically change the set of trade-offs that have proven themselves to be quite successful.
aldanor 3y ago
To think about it, perhaps US should have started metrification back in 1980 when EU enforced it for its members. It takes time, but is doable - if took Ireland 25 years to fully switch to metric. The cost of switching increases over time and will increase further and further, making it less and less likely. Would have been way cheaper back then.
- dragonwriter 3y ago
  > To think about it, perhaps US should have started metrification back in 1980 The US started that in either 1875 or 1893, though, and somewhat more aggressively in 1975. It reversed course in the 1980s, it didn't fail to start before that.
Groxx 3y ago
Removing the GIL will also make some currently-correct threaded code into incorrect code, since the GIL gives some convenient default safety that I keep seeing people accidentally rely on without knowing it exists. Unavoidable performance costs and reduced safety equals massive friction no matter how it's approached. It's not a question of "are we smart enough to make this better in every way", since the answer is "no, and nobody can be, because it can't be done". It's only "will we make this divisive change".
deleted 3y ago
[deleted]
soulbadguy 3y ago
> That just is doing an incredible amount of heavy lifting. It'd be like saying, "Why doesn't the USA just switch entirely to the metric system?" It's a huge ask, and after being burned by the 2/3 transition, the python team is loathe to rock to boat too much again. > The GIL is deep, arguably one of the deepest abstractions in the codebase, up there with PyObject itself. Think about having to redefine the String implementation of a codebase in your language of choice. I am somewhat familiar with the cpython code base, and talk to some folks involves in some of thousand new python runtime. The problem is not that deep, and cpython is not that much different from other projects : the GIL is an implementation details that leaked through the API and now we have a bunch of people are relying on it. The question is what do we do about it. The trade-off in such situation are well known and just a question to pick the right one. > The team has already decided those tradeoffs are not really justifiable. That's from my view the crust of the issue, the TLDR is that GIL-less python is not a priority for the python team, so they view any trade-off/comprise as "not justifiable". Especially something when it come to added complexity to the code base or what not... > Person with limited to zero experience with CPython internals> I hate the GIL, why don't they just remove it? People have this reaction because having a single-threaded interpreter in 2023 is just ... embarrassing, what ever the reasons behind it.
- nunuvit 3y ago
  It only takes a couple of minutes to educate yourself on this topic. After reading it, let me know if you still think they don't want to compromise. https://www.artima.com/weblogs/viewpost.jsp?thread=214235 https://www.artima.com/weblogs/viewpost.jsp?thread=214235
  - soulbadguy 3y ago
    > It only takes a couple of minutes to educate yourself on this topic. You can disagree without assuming that i am not familiar with the subject. The link you provided is from 2007 so i am not sure how fair it is to quote guido from then. But i am not sure the link demonstrate the point you are trying to make, from guido himself : > While it is my personal opinion, based upon the above considerations, that there isn't enough value in removing the GIL to warrant the effort. Edit : If you want a newer reference, this HN threads and the links discribe the situation well https://news.ycombinator.com/item?id=36240998 https://news.ycombinator.com/item?id=36240998 Which is the point i am making... This is not really a technical issue, the python just doesn't think it's worth the effort.
kmod 3y ago
You should check out the new nogil project by Sam Gross, which is what's being talked about these days -- he actually successfully removed the gil, but yes with the tradeoffs that you mention. The other projects were, by comparison, "attempts" to remove the gil, and didn't address core issues such as ownership races (which are far harder than making refcount operations atomic).
- kortex 3y ago
  I indirectly referenced it. IIRC the main problems with his approach are the ABI problem and the mutex overhead. He tries to "solve" the performance hit by offsetting with performance gains elsewhere, but that raises the question "why not take the gains by themselves".

by kortex 3y ago

arp242 3y ago

There were already patches to "just" remove the GIL for Python 2.0 or thereabouts, over 20 years ago. Strictly technically speaking it's not even that hard, but as you mentioned it comes with all sorts of trade-offs. Today Python is one of the world's most popular programming language, if not the most popular language. The GIL is limiting and a trade-off in itself of course – designing any programming language is an exercise in trade-offs. But clearly Python has gotten quite far with the set of trade-offs it has chosen: you need to be careful to "just" radically change the set of trade-offs that have proven themselves to be quite successful.

aldanor 3y ago

To think about it, perhaps US should have started metrification back in 1980 when EU enforced it for its members. It takes time, but is doable - if took Ireland 25 years to fully switch to metric. The cost of switching increases over time and will increase further and further, making it less and less likely. Would have been way cheaper back then.

dragonwriter 3y ago
> To think about it, perhaps US should have started metrification back in 1980 The US started that in either 1875 or 1893, though, and somewhat more aggressively in 1975. It reversed course in the 1980s, it didn't fail to start before that.

Groxx 3y ago

Removing the GIL will also make some currently-correct threaded code into incorrect code, since the GIL gives some convenient default safety that I keep seeing people accidentally rely on without knowing it exists. Unavoidable performance costs and reduced safety equals massive friction no matter how it's approached. It's not a question of "are we smart enough to make this better in every way", since the answer is "no, and nobody can be, because it can't be done". It's only "will we make this divisive change".

deleted 3y ago

[deleted]

soulbadguy 3y ago

> That just is doing an incredible amount of heavy lifting. It'd be like saying, "Why doesn't the USA just switch entirely to the metric system?" It's a huge ask, and after being burned by the 2/3 transition, the python team is loathe to rock to boat too much again. > The GIL is deep, arguably one of the deepest abstractions in the codebase, up there with PyObject itself. Think about having to redefine the String implementation of a codebase in your language of choice. I am somewhat familiar with the cpython code base, and talk to some folks involves in some of thousand new python runtime. The problem is not that deep, and cpython is not that much different from other projects : the GIL is an implementation details that leaked through the API and now we have a bunch of people are relying on it. The question is what do we do about it. The trade-off in such situation are well known and just a question to pick the right one. > The team has already decided those tradeoffs are not really justifiable. That's from my view the crust of the issue, the TLDR is that GIL-less python is not a priority for the python team, so they view any trade-off/comprise as "not justifiable". Especially something when it come to added complexity to the code base or what not... > Person with limited to zero experience with CPython internals> I hate the GIL, why don't they just remove it? People have this reaction because having a single-threaded interpreter in 2023 is just ... embarrassing, what ever the reasons behind it.

nunuvit 3y ago
It only takes a couple of minutes to educate yourself on this topic. After reading it, let me know if you still think they don't want to compromise. https://www.artima.com/weblogs/viewpost.jsp?thread=214235 https://www.artima.com/weblogs/viewpost.jsp?thread=214235
- soulbadguy 3y ago
  > It only takes a couple of minutes to educate yourself on this topic. You can disagree without assuming that i am not familiar with the subject. The link you provided is from 2007 so i am not sure how fair it is to quote guido from then. But i am not sure the link demonstrate the point you are trying to make, from guido himself : > While it is my personal opinion, based upon the above considerations, that there isn't enough value in removing the GIL to warrant the effort. Edit : If you want a newer reference, this HN threads and the links discribe the situation well https://news.ycombinator.com/item?id=36240998 https://news.ycombinator.com/item?id=36240998 Which is the point i am making... This is not really a technical issue, the python just doesn't think it's worth the effort.

kmod 3y ago

You should check out the new nogil project by Sam Gross, which is what's being talked about these days -- he actually successfully removed the gil, but yes with the tradeoffs that you mention. The other projects were, by comparison, "attempts" to remove the gil, and didn't address core issues such as ownership races (which are far harder than making refcount operations atomic).

kortex 3y ago
I indirectly referenced it. IIRC the main problems with his approach are the ABI problem and the mutex overhead. He tries to "solve" the performance hit by offsetting with performance gains elsewhere, but that raises the question "why not take the gains by themselves".