9 ms·

Yeah, they clearly stated that here https://discuss.python.org/t/pep-703-making-the-global-interpreter-lock-optional-3-12-updates/26503/118 https://discuss.pyth

by bratao 3y ago

Yeah, they clearly stated that here https://discuss.python.org/t/pep-703-making-the-global-interpreter-lock-optional-3-12-updates/26503/118 https://discuss.python.org/t/pep-703-making-the-global-inter... I really wish that GIL go away. It is better to pay this price now, multi-threading is the future.

hospitalJail 3y ago
I'm so conflicted. ~40 of the programs I am responsible for are single threaded. They were relatively quick to develop and were made by Electrical Engineers rather than career/degreed programmers. 2 programs use multithreading, I had to do that. The learning curve was not a huge deal, but the development time adds at least hours. In my case days(due to testing). I imagine its too hard to have an optional flag at the start of each program that can let the user decide?
- birdyrooster 3y ago
  The problem is that Python types are not thread safe so you have to jump through more hoops to have safe parallelization in Python. These changes would make it so that writing multithreaded code will be much easier it seems like.
- maleldil 3y ago
  > I imagine its too hard to have an optional flag at the start of each program that can let the user decide? Adding nogil would mean deep changes to the interpreter. I imagine maintaining both versions would be almost like forking the project.
- coldtea 3y ago
  >but the development time adds at least hours So? some "hours of development time" is nothing.
  - sfink 3y ago
    True, and as you get better at it, those hours will be fewer. The weeks of debugging never go away, though. (Or at least, not as long as you're using shared state, but that's really the only thing under consideration here.)
  - hospitalJail 3y ago
    I'm mostly with you. I think this probably affects part time/newbie programmers more. A few hours of dev time is 1 or 2 nights of work.
- dragonwriter 3y ago
  > I imagine its too hard to have an optional flag at the start of each program that can let the user decide? The actual next-step proposal toward no-gil is GIL as a build-time flag (which isn’t quite the same as a runtime flag, but not too far off, either.) https://peps.python.org/pep-0703/ https://peps.python.org/pep-0703/
- nunuvit 3y ago
  It's not like CPython is depriving anyone of GIL-free Python. IronPython and Jython are GIL-free. You can have it yesterday. CPython maintains Python's original purpose as a glue language. You know how much worse CPython would be for that use-case without the GIL. GVR has said he'll support removing the GIL as long as there's no performance hit. Otherwise, it's simply asking for a fundamental change of direction and too much sacrifice from everyone who needs CPython specifically, just to improve the productivity of people who could use a different Python.
sgt 3y ago
Not for Python, I feel. In sheer volume, the vast majority of my Python programs are single-threaded. I want my programs to be very quick in runtime when they run. Those that are multi-threaded are seeing minor to medium load. If expecting extreme load (like Twitter scale), then Python is usually not the answer (rather go to a statically typed language like Java, Go, Rust etc).
- gpderetta 3y ago
  > In sheer volume, the vast majority of my Python programs are single-threaded obviously if multithreading is near-useless in python, very few programs will take advantage of it.
  - zo1 3y ago
    Likewise I can say: Obviously we still have the GIL because very few people want it removed.
    - gpderetta 3y ago
      Well, yes, that's pretty much obvious: the majority of python programmers do not care, those that cared have moved on as it is easier than changing the language. And I'll be first to admit that improving single threaded performance has an higher priority than removing the GIL.
- AlphaSite 3y ago
  Is single threaded perf is important, you’ve already lost by using python. You’re only ever going to get, ok-ish performance or slightly more ok-ish
- gcbirzan 3y ago
  > Not for Python, I feel. In sheer volume, the vast majority of my Python programs are single-threaded. Yes, they are single threaded, because using multiple threads brings very little benefit in most cases... > If expecting extreme load (like Twitter scale), then Python is usually not the answer (rather go to a statically typed language like Java, Go, Rust etc). So that means we shouldn't get any performance improvements, because there are faster languages out there?
amelius 3y ago
It's relatively simple to make the GIL go away: just compile to some VM that has a good concurrent garbage collector would be one approach. Yes, this will break some assumptions here and there, but not too difficult to overcome especially if you bump the version number to Python 4. However, that leaves a lot of C code that you can't talk to anymore because the C code requires the old Python FFI. I think this is where the main problem lies.
- notatallshaw 3y ago
  > It's relatively simple to make the GIL go away: just compile to some VM that has a good concurrent garbage collector would be one approach Sure, if you don't mind paying a 50-90% performance impact on single threaded performance or completely abandon C-API compatibility and have C extensions start from scratch then there are simple approaches. If you look at any example in the past to remove the GIL you would see that keeping these two requirements of not having terrible single threaded performance and not having almost a completely new C-API is actually very complex and takes a lot of expertise to implement.
  - saltminer 3y ago
    This might be a dumb question, but why would removing the GIL break FFI? Is it just that existing no-GIL implementations/proposals have discarded/ignored it, or is there a fundamental requirement, e.g. C programs unavoidably interact directly with the GIL? (In which case, couldn't a "legacy FFI" wrapper be created?) I know that the C-API is only stable between minor releases [0] compiled in the same manner [1], so it's not like the ecosystem is dependent upon it never changing. I cannot seem to find much discussion about this. I have found a no-GIL interpreter that works with numpy, scikit, etc. [2][3] so it doesn't seem to be a hard limit. (That said, it was not stated if that particular no-GIL implementation requires specially built versions of C-API libs or if it's a drop-in replacement.) [0]: https://docs.python.org/3/c-api/stable.html#c-api-stability https://docs.python.org/3/c-api/stable.html#c-api-stability [1]: https://docs.python.org/3/c-api/stable.html#platform-considerations https://docs.python.org/3/c-api/stable.html#platform-conside... [2]: https://github.com/colesbury/nogil https://github.com/colesbury/nogil [3]: https://discuss.python.org/t/pep-703-making-the-global-interpreter-lock-optional-3-12-updates/26503/28 https://discuss.python.org/t/pep-703-making-the-global-inter...
PhilipRoman 3y ago
>multi-threading is the future Haha, reminds me of an image I saw with a farmer from some developing country saying "irrigation is the future". For everyone else multithreading has been the status quo for quite a long time.
ActorNightly 3y ago
>multi-threading is the future. Yes, with ML powered compilers recognizing what you are trying to do and generating the actual multithreaded code for you. And it won't be multithreaded code like you know it, in the sense of os specific threading code with context switching and what not. It will be compiled compute graphs targeted at specific ML hardware, likely with static addressing.

by bratao 3y ago

hospitalJail 3y ago

I'm so conflicted. ~40 of the programs I am responsible for are single threaded. They were relatively quick to develop and were made by Electrical Engineers rather than career/degreed programmers. 2 programs use multithreading, I had to do that. The learning curve was not a huge deal, but the development time adds at least hours. In my case days(due to testing). I imagine its too hard to have an optional flag at the start of each program that can let the user decide?

birdyrooster 3y ago
The problem is that Python types are not thread safe so you have to jump through more hoops to have safe parallelization in Python. These changes would make it so that writing multithreaded code will be much easier it seems like.
maleldil 3y ago
> I imagine its too hard to have an optional flag at the start of each program that can let the user decide? Adding nogil would mean deep changes to the interpreter. I imagine maintaining both versions would be almost like forking the project.
coldtea 3y ago
>but the development time adds at least hours So? some "hours of development time" is nothing.
- sfink 3y ago
  True, and as you get better at it, those hours will be fewer. The weeks of debugging never go away, though. (Or at least, not as long as you're using shared state, but that's really the only thing under consideration here.)
- hospitalJail 3y ago
  I'm mostly with you. I think this probably affects part time/newbie programmers more. A few hours of dev time is 1 or 2 nights of work.
dragonwriter 3y ago
> I imagine its too hard to have an optional flag at the start of each program that can let the user decide? The actual next-step proposal toward no-gil is GIL as a build-time flag (which isn’t quite the same as a runtime flag, but not too far off, either.) https://peps.python.org/pep-0703/ https://peps.python.org/pep-0703/
nunuvit 3y ago
It's not like CPython is depriving anyone of GIL-free Python. IronPython and Jython are GIL-free. You can have it yesterday. CPython maintains Python's original purpose as a glue language. You know how much worse CPython would be for that use-case without the GIL. GVR has said he'll support removing the GIL as long as there's no performance hit. Otherwise, it's simply asking for a fundamental change of direction and too much sacrifice from everyone who needs CPython specifically, just to improve the productivity of people who could use a different Python.

sgt 3y ago

Not for Python, I feel. In sheer volume, the vast majority of my Python programs are single-threaded. I want my programs to be very quick in runtime when they run. Those that are multi-threaded are seeing minor to medium load. If expecting extreme load (like Twitter scale), then Python is usually not the answer (rather go to a statically typed language like Java, Go, Rust etc).

gpderetta 3y ago
> In sheer volume, the vast majority of my Python programs are single-threaded obviously if multithreading is near-useless in python, very few programs will take advantage of it.
- zo1 3y ago
  Likewise I can say: Obviously we still have the GIL because very few people want it removed.
  - gpderetta 3y ago
    Well, yes, that's pretty much obvious: the majority of python programmers do not care, those that cared have moved on as it is easier than changing the language. And I'll be first to admit that improving single threaded performance has an higher priority than removing the GIL.
AlphaSite 3y ago
Is single threaded perf is important, you’ve already lost by using python. You’re only ever going to get, ok-ish performance or slightly more ok-ish
gcbirzan 3y ago
> Not for Python, I feel. In sheer volume, the vast majority of my Python programs are single-threaded. Yes, they are single threaded, because using multiple threads brings very little benefit in most cases... > If expecting extreme load (like Twitter scale), then Python is usually not the answer (rather go to a statically typed language like Java, Go, Rust etc). So that means we shouldn't get any performance improvements, because there are faster languages out there?

amelius 3y ago

It's relatively simple to make the GIL go away: just compile to some VM that has a good concurrent garbage collector would be one approach. Yes, this will break some assumptions here and there, but not too difficult to overcome especially if you bump the version number to Python 4. However, that leaves a lot of C code that you can't talk to anymore because the C code requires the old Python FFI. I think this is where the main problem lies.

notatallshaw 3y ago
> It's relatively simple to make the GIL go away: just compile to some VM that has a good concurrent garbage collector would be one approach Sure, if you don't mind paying a 50-90% performance impact on single threaded performance or completely abandon C-API compatibility and have C extensions start from scratch then there are simple approaches. If you look at any example in the past to remove the GIL you would see that keeping these two requirements of not having terrible single threaded performance and not having almost a completely new C-API is actually very complex and takes a lot of expertise to implement.
- saltminer 3y ago
  This might be a dumb question, but why would removing the GIL break FFI? Is it just that existing no-GIL implementations/proposals have discarded/ignored it, or is there a fundamental requirement, e.g. C programs unavoidably interact directly with the GIL? (In which case, couldn't a "legacy FFI" wrapper be created?) I know that the C-API is only stable between minor releases [0] compiled in the same manner [1], so it's not like the ecosystem is dependent upon it never changing. I cannot seem to find much discussion about this. I have found a no-GIL interpreter that works with numpy, scikit, etc. [2][3] so it doesn't seem to be a hard limit. (That said, it was not stated if that particular no-GIL implementation requires specially built versions of C-API libs or if it's a drop-in replacement.) [0]: https://docs.python.org/3/c-api/stable.html#c-api-stability https://docs.python.org/3/c-api/stable.html#c-api-stability [1]: https://docs.python.org/3/c-api/stable.html#platform-considerations https://docs.python.org/3/c-api/stable.html#platform-conside... [2]: https://github.com/colesbury/nogil https://github.com/colesbury/nogil [3]: https://discuss.python.org/t/pep-703-making-the-global-interpreter-lock-optional-3-12-updates/26503/28 https://discuss.python.org/t/pep-703-making-the-global-inter...

PhilipRoman 3y ago

>multi-threading is the future Haha, reminds me of an image I saw with a farmer from some developing country saying "irrigation is the future". For everyone else multithreading has been the status quo for quite a long time.

ActorNightly 3y ago

>multi-threading is the future. Yes, with ML powered compilers recognizing what you are trying to do and generating the actual multithreaded code for you. And it won't be multithreaded code like you know it, in the sense of os specific threading code with context switching and what not. It will be compiled compute graphs targeted at specific ML hardware, likely with static addressing.