5 ms·

> This "optimization" actually slows single-threaded accesses down slightly, according to the design document, but that penalty becomes worthwhile once multi-th

> This "optimization" actually slows single-threaded accesses down slightly, according to the design document, but that penalty becomes worthwhile once multi-threaded execution becomes possible. My understanding was that CPython viewed any single-threaded performance regression as a blocker to GIL-removal attempts, regardless of if other work by the developer has sped up the interpreter? This article seems to somewhat gloss over that with "it's only small". I'd be interested in knowing other estimations of what the "better-than-average chance" of this (promising sounding) attempt were. Breaking C extensions (especially the less-conforming ones, which seem likely to be the least maintained) also seems like it would be a very hard pill to swallow, and the sort of thing that might make it a Python 3-to-4 breaking change, which I imagine would also be approached extremely carefully given there are still people to-this-day who believe that python 3 is a mistake and one day everyone will realise it and go back to python 2 (yes, really).

fatbird 5y ago
It was Guido's requirement that GIL removal not degrade single threaded performance at all, but in the talk I attend at PyCon 2019, the speaker mentioned nothing about qualifications on that. Guido's restriction was presented, quite reasonably, as "no one should have to suffer because of removing the GIL". So a net break-even or performance improvement is fine. And on top of that, Guido has retired now, and the steering committee may feel differently as long as the spirit of the restrictions is upheld.
- fatbird 5y ago
  Guido has replied to Gross's announcement to observe that his performance improvements are not tied to removing the GIL and could be accepted separately. But he doesn't reject Gross's work outright, and if the same release that includes the GIL removal also delivers a concrete performance upgrade, I suspect that Guido would be fine with it. His concern is, after all, practical, to do with the actual use of python and not some architecture principle.
  - cormacrelf 5y ago
    I'm not saying this is a good idea (it is not, please don't do this to your open source community of choice!) but it'd be a pretty funny use of copyright licensing to reserve all rights on the non-GIL improvements unless the GIL ones were also merged. Strong-arming an open source project with sheer programming skill.
singhrac 5y ago
From the article: > Gross has also put some significant work into improving the performance of the CPython interpreter in general. This was done to address the concern that has blocked GIL-removal work in the past: the performance impact on single-threaded code. The end result is that the new interpreter is 10% faster than CPython 3.9 for single-threaded programs.
- singhrac 5y ago
  Sorry, to be clear, I missed your point "regardless of if other work by the developer has sped up the interpreter". That's fair, though my personal opinion is that that seems like an incredibly high bar for any language.
a1369209993 5y ago
> and one day everyone will realise it No? Why would we think that? There are people who willingly use java; compared to that the problems with python 3 are downright non-obvious as long as you never need to work with things like non-Unicode text.
masklinn 5y ago
> My understanding was that CPython viewed any single-threaded performance regression as a blocker to GIL-removal attempts, regardless of if other work by the developer has sped up the interpreter? Previous GILectomy attempts incurred significant single-threaded performance penalties, on on the order of 50% or above. If Gross's work yields low single-digit performance penalty it's pretty likely to be accepted as this is the sort of impacts which can happen semi-routinely as part of interpreter updates. The complete breakage of C extensions would be a much bigger issue.
- solarmist 5y ago
  The article mentions a 10% improvement to single threaded runtime on average.
  - arc-in-space 5y ago
    Yes, but this speedup comes from essentially unrelated changes from the same contributor, not from the parallelization work, which by itself would be a small slowdown (assuming the article is accurate).
ajkjk 5y ago
There are people who believe all kinds of crazy things; it doesn't reflect their truth. Going back to Python 2 is not going to ever happen (and no one working on Py3 would ever want to, anyway). A hard pill to swallow.. ain't that bad if it also benefits you tremendously, which fixing the GIL would do.
- EamonnMR 5y ago
  I do wish for a world where Python 3 had handled unicode/bytes very differently.
Kranar 5y ago
C extensions can continue to be supported. Said extensions already explicitly lock/release the GIL, so to keep things backwards compatible it would be perfectly fine if there was a GIL that existed strictly for C extension compatibility.

fatbird 5y ago

It was Guido's requirement that GIL removal not degrade single threaded performance at all, but in the talk I attend at PyCon 2019, the speaker mentioned nothing about qualifications on that. Guido's restriction was presented, quite reasonably, as "no one should have to suffer because of removing the GIL". So a net break-even or performance improvement is fine. And on top of that, Guido has retired now, and the steering committee may feel differently as long as the spirit of the restrictions is upheld.

fatbird 5y ago
Guido has replied to Gross's announcement to observe that his performance improvements are not tied to removing the GIL and could be accepted separately. But he doesn't reject Gross's work outright, and if the same release that includes the GIL removal also delivers a concrete performance upgrade, I suspect that Guido would be fine with it. His concern is, after all, practical, to do with the actual use of python and not some architecture principle.
- cormacrelf 5y ago
  I'm not saying this is a good idea (it is not, please don't do this to your open source community of choice!) but it'd be a pretty funny use of copyright licensing to reserve all rights on the non-GIL improvements unless the GIL ones were also merged. Strong-arming an open source project with sheer programming skill.

singhrac 5y ago

From the article: > Gross has also put some significant work into improving the performance of the CPython interpreter in general. This was done to address the concern that has blocked GIL-removal work in the past: the performance impact on single-threaded code. The end result is that the new interpreter is 10% faster than CPython 3.9 for single-threaded programs.

singhrac 5y ago
Sorry, to be clear, I missed your point "regardless of if other work by the developer has sped up the interpreter". That's fair, though my personal opinion is that that seems like an incredibly high bar for any language.

a1369209993 5y ago

> and one day everyone will realise it No? Why would we think that? There are people who willingly use java; compared to that the problems with python 3 are downright non-obvious as long as you never need to work with things like non-Unicode text.

masklinn 5y ago

> My understanding was that CPython viewed any single-threaded performance regression as a blocker to GIL-removal attempts, regardless of if other work by the developer has sped up the interpreter? Previous GILectomy attempts incurred significant single-threaded performance penalties, on on the order of 50% or above. If Gross's work yields low single-digit performance penalty it's pretty likely to be accepted as this is the sort of impacts which can happen semi-routinely as part of interpreter updates. The complete breakage of C extensions would be a much bigger issue.

solarmist 5y ago
The article mentions a 10% improvement to single threaded runtime on average.
- arc-in-space 5y ago
  Yes, but this speedup comes from essentially unrelated changes from the same contributor, not from the parallelization work, which by itself would be a small slowdown (assuming the article is accurate).

ajkjk 5y ago

There are people who believe all kinds of crazy things; it doesn't reflect their truth. Going back to Python 2 is not going to ever happen (and no one working on Py3 would ever want to, anyway). A hard pill to swallow.. ain't that bad if it also benefits you tremendously, which fixing the GIL would do.

EamonnMR 5y ago
I do wish for a world where Python 3 had handled unicode/bytes very differently.

Kranar 5y ago

C extensions can continue to be supported. Said extensions already explicitly lock/release the GIL, so to keep things backwards compatible it would be perfectly fine if there was a GIL that existed strictly for C extension compatibility.