7 ms·

There was always a denial of removing the Global Interpreter Lock because it would decrease single threaded Python speed for which most people din’t care. So I

by antman 4y ago

There was always a denial of removing the Global Interpreter Lock because it would decrease single threaded Python speed for which most people din’t care. So I remember a guy recently came up with a patch that both removed GIL and also to make it easier for the core team to accept it he added also an equivalent number of optimizations. I hope this release was is not we got the optimizations but ignored the GIL part. If anyone more knowledgable can review this and give some feedback I think will be here in HN

didip 4y ago
I agree, please don't just accept the optimization and sweep the GIL removal under the rug again.
nmstoker 4y ago
I think you mean the work by Sam Gross: https://github.com/colesbury/nogil/ https://github.com/colesbury/nogil/ Interesting article about it here: https://lukasz.langa.pl/5d044f91-49c1-4170-aed1-62b6763e6ad0/ https://lukasz.langa.pl/5d044f91-49c1-4170-aed1-62b6763e6ad0...
BerislavLopac 4y ago
The GIL removal by that guy reverted some of the improvement done by other optimisations, so the overall improvement was much smaller. And most people do care for single-threaded speed, because the vast majority of Python software is written as single-threaded.
- metadat 4y ago
  > the vast majority of Python software is written as single-threaded. This is a self-fulfilling prophecy, as the GIL makes Python's (and Ruby's) concurrency story pretty rough compared to nearly all other widely used languages: C, C++, Java, Go, Rust, and even Javascript (as of late).
  - SiempreViernes 4y ago
    Pretty sure it is actually a statement that comes from the "python is a scripting language" school, and not because the huge horde of programmers that craves concurrency when they write a script to reformat a log file to csv keeps being put off by the python multiprocessing story.
    - metadat 4y ago
      Not sure I understand your point, can you clarify? Python is used across many different domains, being able to really take advantage of multiple cores would be a big deal. I'd really appreciate if python included concurrency or parallelism capabilities that didn't disappoint and frustrate me. If you've tried using the thread module, multiprocessing module, or async function coloring feature, you probably can relate. They can sort of work but are about as appealing as being probed internally in a medical setting.
      - pclmulqdq 4y ago
        I'm not the person you responded to, but I think the gist of it is: what it is is not defined by how it is used. Python, at its core, is a scripting language, like awk and bash. The other uses don't change that. Occasionally, a technology breaks out of its intended domain. Python is one of these - it plays host to lots of webservers, and even a filesystem (dropbox). Similarly, HTML is a text markup language, but that doesn't stop people from making video games using it. The developers of the technology now have to make a philosophical decision about what that technology is. They can decide to re-optimize for the current use cases and risk losing the heart of their technology as tradeoffs get made, or they can decide to keep the old vision. All of the design choices flow down from the vision. They have decided that Python is a scripting language. Personally, I agree (https://specbranch.com/posts/python-and-asm/ https://specbranch.com/posts/python-and-asm/). In turn, the people using the language for something other than its intended purpose have choices to make - including whether to abandon the technology. If instead Python moves toward competing with languages like go, it is going to need to make a lot of different tradeoffs. Ditching the GIL comes with tradeoffs of making Python slower for those who just want to write scripts. Adding more rigorous scoping would make it easier to have confidence in a production server, but harder to tinker. Everything comes with tradeoffs, and decisions on those tradeoffs come from the values of the development team. Right now, they value scripting.
- magic_hamster 4y ago
  A lot of python runs in celery and possibly even more python runs parallelized cuda code. Not sure at all the majority of python code is single threaded, especially for more serious projects.
jart 4y ago
I use a beautiful hack in the Cosmopolitan Libc codebase (x86 only) where we rewrite NOPs into function calls at runtime for all locking operations as soon as clone() is called. https://github.com/jart/cosmopolitan/blob/5df3e4e7a898d223ce9bd646e37345ef7c54f84e/libc/runtime/threadmode.c#L37 https://github.com/jart/cosmopolitan/blob/5df3e4e7a898d223ce... The big ugly macro that makes it work is here https://github.com/jart/cosmopolitan/blob/master/libc/intrin/nopl.h https://github.com/jart/cosmopolitan/blob/master/libc/intrin... An example of how it's used is here. https://github.com/jart/cosmopolitan/blob/5df3e4e7a898d223ce9bd646e37345ef7c54f84e/libc/intrin/cxaatexit.internal.h#L23 https://github.com/jart/cosmopolitan/blob/5df3e4e7a898d223ce... What it means is that things like stdio goes 3x faster if you're not actually using threads. The tradeoff is it's architecture specific and requires self-modifying code. Maybe something like this could help Python?
- pm 4y ago
  I would love to see this implemented purely for curiosity's sake, even if it's architecture-specific. Personally, cosmo is one of those projects that inspires me to crack out C again, even though I was never understood the CPU's inner workings very well, and your work in general speaks to the pure joy that programming can be as an act of creation. Thanks for all your contributions to the community, and thanks for being you!
- jfim 4y ago
  That's a pretty clever hack, nicely done!
deleted 4y ago
[deleted]
lrtap 4y ago
> I hope this release was is not we got the optimizations but ignored the GIL part. I would not be surprised. It is highly likely that the optimizations will be taken, credit will go to the usual people and the GIL part will be extinguished.
int_19h 4y ago
Removing GIL also breaks existing native packages, and would require wholesale migration across the entire ecosystem, on a scale not dissimilar to what we've seen with Python 3.
- smcl 4y ago
  The various trade-offs and potential pitfalls involved in removing the GIL are by now very well known, not just here on HN but among the Python core developers who will ultimately do the heavy lifting when it comes to doing this work.
- icegreentea2 4y ago
  They believe that the current nogil approach can allow the vast majority of c-extension packages to adapt with a re-compile, or at worst relatively minor code changes (they thought it would be ~15 lines for numpy for example). Since c-extension wheels are basically built for single python versions anyways, this is potentially manageable.
- josefx 4y ago
  > on a scale not dissimilar to what we've seen with Python 3. If only people had asked for it before the Python 3 migration so it could have been done with all the other breaking and performance harming changes. But no, people only started to ask for it literally yesterday so it just could not ever be done, my bad. /sarcasm If anything the whole Python 3 migration makes any argument against the removal of the GIL appear dishonest to me. It should have been gone decades ago and still wasn't included in the biggest pile of breaking changes the language went through .
  - gpderetta 4y ago
    We didn't get any performance improvements, but at least now we can call print from lambda functions, that's was certainly worth the massive breakage.
  - ModernMech 4y ago
    I think probably the reason is that in 2008, consumer chips were still mostly single or dual core. Today we have consumer grade chips that have dozens of cores, so the calculus has changed.
deleted 4y ago
[deleted]

by antman 4y ago

didip 4y ago

I agree, please don't just accept the optimization and sweep the GIL removal under the rug again.

nmstoker 4y ago

I think you mean the work by Sam Gross: https://github.com/colesbury/nogil/ https://github.com/colesbury/nogil/ Interesting article about it here: https://lukasz.langa.pl/5d044f91-49c1-4170-aed1-62b6763e6ad0/ https://lukasz.langa.pl/5d044f91-49c1-4170-aed1-62b6763e6ad0...

BerislavLopac 4y ago

The GIL removal by that guy reverted some of the improvement done by other optimisations, so the overall improvement was much smaller. And most people do care for single-threaded speed, because the vast majority of Python software is written as single-threaded.

metadat 4y ago
> the vast majority of Python software is written as single-threaded. This is a self-fulfilling prophecy, as the GIL makes Python's (and Ruby's) concurrency story pretty rough compared to nearly all other widely used languages: C, C++, Java, Go, Rust, and even Javascript (as of late).
- SiempreViernes 4y ago
  Pretty sure it is actually a statement that comes from the "python is a scripting language" school, and not because the huge horde of programmers that craves concurrency when they write a script to reformat a log file to csv keeps being put off by the python multiprocessing story.
  - metadat 4y ago
    Not sure I understand your point, can you clarify? Python is used across many different domains, being able to really take advantage of multiple cores would be a big deal. I'd really appreciate if python included concurrency or parallelism capabilities that didn't disappoint and frustrate me. If you've tried using the thread module, multiprocessing module, or async function coloring feature, you probably can relate. They can sort of work but are about as appealing as being probed internally in a medical setting.
    - pclmulqdq 4y ago
      I'm not the person you responded to, but I think the gist of it is: what it is is not defined by how it is used. Python, at its core, is a scripting language, like awk and bash. The other uses don't change that. Occasionally, a technology breaks out of its intended domain. Python is one of these - it plays host to lots of webservers, and even a filesystem (dropbox). Similarly, HTML is a text markup language, but that doesn't stop people from making video games using it. The developers of the technology now have to make a philosophical decision about what that technology is. They can decide to re-optimize for the current use cases and risk losing the heart of their technology as tradeoffs get made, or they can decide to keep the old vision. All of the design choices flow down from the vision. They have decided that Python is a scripting language. Personally, I agree (https://specbranch.com/posts/python-and-asm/ https://specbranch.com/posts/python-and-asm/). In turn, the people using the language for something other than its intended purpose have choices to make - including whether to abandon the technology. If instead Python moves toward competing with languages like go, it is going to need to make a lot of different tradeoffs. Ditching the GIL comes with tradeoffs of making Python slower for those who just want to write scripts. Adding more rigorous scoping would make it easier to have confidence in a production server, but harder to tinker. Everything comes with tradeoffs, and decisions on those tradeoffs come from the values of the development team. Right now, they value scripting.
magic_hamster 4y ago
A lot of python runs in celery and possibly even more python runs parallelized cuda code. Not sure at all the majority of python code is single threaded, especially for more serious projects.

jart 4y ago

I use a beautiful hack in the Cosmopolitan Libc codebase (x86 only) where we rewrite NOPs into function calls at runtime for all locking operations as soon as clone() is called. https://github.com/jart/cosmopolitan/blob/5df3e4e7a898d223ce9bd646e37345ef7c54f84e/libc/runtime/threadmode.c#L37 https://github.com/jart/cosmopolitan/blob/5df3e4e7a898d223ce... The big ugly macro that makes it work is here https://github.com/jart/cosmopolitan/blob/master/libc/intrin/nopl.h https://github.com/jart/cosmopolitan/blob/master/libc/intrin... An example of how it's used is here. https://github.com/jart/cosmopolitan/blob/5df3e4e7a898d223ce9bd646e37345ef7c54f84e/libc/intrin/cxaatexit.internal.h#L23 https://github.com/jart/cosmopolitan/blob/5df3e4e7a898d223ce... What it means is that things like stdio goes 3x faster if you're not actually using threads. The tradeoff is it's architecture specific and requires self-modifying code. Maybe something like this could help Python?

pm 4y ago
I would love to see this implemented purely for curiosity's sake, even if it's architecture-specific. Personally, cosmo is one of those projects that inspires me to crack out C again, even though I was never understood the CPU's inner workings very well, and your work in general speaks to the pure joy that programming can be as an act of creation. Thanks for all your contributions to the community, and thanks for being you!
jfim 4y ago
That's a pretty clever hack, nicely done!

deleted 4y ago

[deleted]

lrtap 4y ago

> I hope this release was is not we got the optimizations but ignored the GIL part. I would not be surprised. It is highly likely that the optimizations will be taken, credit will go to the usual people and the GIL part will be extinguished.

int_19h 4y ago

Removing GIL also breaks existing native packages, and would require wholesale migration across the entire ecosystem, on a scale not dissimilar to what we've seen with Python 3.

smcl 4y ago
The various trade-offs and potential pitfalls involved in removing the GIL are by now very well known, not just here on HN but among the Python core developers who will ultimately do the heavy lifting when it comes to doing this work.
icegreentea2 4y ago
They believe that the current nogil approach can allow the vast majority of c-extension packages to adapt with a re-compile, or at worst relatively minor code changes (they thought it would be ~15 lines for numpy for example). Since c-extension wheels are basically built for single python versions anyways, this is potentially manageable.
josefx 4y ago
> on a scale not dissimilar to what we've seen with Python 3. If only people had asked for it before the Python 3 migration so it could have been done with all the other breaking and performance harming changes. But no, people only started to ask for it literally yesterday so it just could not ever be done, my bad. /sarcasm If anything the whole Python 3 migration makes any argument against the removal of the GIL appear dishonest to me. It should have been gone decades ago and still wasn't included in the biggest pile of breaking changes the language went through .
- gpderetta 4y ago
  We didn't get any performance improvements, but at least now we can call print from lambda functions, that's was certainly worth the massive breakage.
- ModernMech 4y ago
  I think probably the reason is that in 2008, consumer chips were still mostly single or dual core. Today we have consumer grade chips that have dozens of cores, so the calculus has changed.

deleted 4y ago

[deleted]