5 ms·

From reading the thread on HN the other day, it sounds like removing the GIL isn't really of much value. Maybe for somewhat obscure multithreading cases. Is th

From reading the thread on HN the other day, it sounds like removing the GIL isn't really of much value. Maybe for somewhat obscure multithreading cases. Is that right?

FartyMcFarter 3y ago
I would disagree with that. The GIL means you can't use Python multithreading in order to take advantage of more CPU time by parallelism. Obviously getting rid of the GIL makes that a real option, just as it is in other languages.
squeaky-clean 3y ago
Currently, yes that's kind of true. But it's really only considered obscure because the GIL makes it so you either have to do some weird non thread pattern or go with a different language, and people often go with a different language. Kind of a Catch-22 of "Well no one uses it that way, so why should we make it possible to use it that way? Well, no one uses it that way because it's impossible to use it that way"
kukkamario 3y ago
Well Python doesn't really do proper multi-threading currently thanks to GIL blocking any additional execution threads. So removing it would enable making Python code that is actually multi-threaded without resorting to extra processes and their overhead. So if you are writing small single process Python script then removing GIL shouldn't really change much. If you are doing some heavier computing or eg. running server back-end, then there are significant performance gains available with this change.
- School-Cotton 3y ago
  You don’t have to use separate processes to get the benefit of multithreading in Python today — you can also call into a library written in native code that drops the GIL (e.g. Numpy or Pytorch).
  - masklinn 3y ago
    Even then the GIL can cause issues, concerns of PyTorch are specifically one of the motivations of the PEP, and one of the reasons Meta / FB really really wants this: > In PyTorch, Python is commonly used to orchestrate ~8 GPUs and ~64 CPU threads, growing to 4k GPUs and 32k CPU threads for big models. While the heavy lifting is done outside of Python, the speed of GPUs makes even just the orchestration in Python not scalable. We often end up with 72 processes in place of one because of the GIL. Logging, debugging, and performance tuning are orders-of-magnitude more difficult in this regime, continuously causing lower developer productivity.
    - School-Cotton 3y ago
      I feel like orchestrating thousands of GPUs is such a niche use case that it’s fair to expect the people wanting to do it to learn a more suited language, rather than ruining Python for everyone else.
      - tgv 3y ago
        You are completely right. Why don't they write their stuff in another language? They've got the resources. Now the rest of the world will suffer the consequences, one of which may be that the devs of native libs will simply abandon the work, or that those libs will become too difficult to use for the casual or starting programmer, completely defeating the purpose. I'm fine with two builds, but not a single non-GIL build.
        masklinn 3y ago
        > Now the rest of the world will suffer the consequences, one of which may be that the devs of native libs will simply abandon the work, or that those libs will become too difficult to use for the casual or starting programmer, completely defeating the purpose. Or get the benefits, so casual or starting programmers won't be wondering why their python program refuses to go above 100% CPU, or have to deal with the bullshit of multiprocessing. > I'm fine with two builds, but not a single non-GIL build. The "no-GIL" build has GIL machinery included, it just runs with the GIL disabled by default. You can force it on (https://peps.python.org/pep-0703/#pythongil-environment-variable https://peps.python.org/pep-0703/#pythongil-environment-vari...), and it will automatically enable itself when loading a non-no-gil library (https://peps.python.org/pep-0703/#py-mod-gil-slot https://peps.python.org/pep-0703/#py-mod-gil-slot).
masklinn 3y ago
> Maybe for somewhat obscure multithreading cases. They're only "somewhat obscure" because currently you can't do it at all, so you don't do it and you do something else: it's of value for any case where you're multithreading for computational parallelism (as opposed to IO concurrency). The PEP also outlines a bunch of other situations where using process-based parallelism is problematic: https://peps.python.org/pep-0703/#motivation https://peps.python.org/pep-0703/#motivation With the proviso that while it will work for all pure-python code out of the box[0] loading any native package which has not opted into "no gil" mode will re-enable the GIL: https://peps.python.org/pep-0703/#py-mod-gil-slot https://peps.python.org/pep-0703/#py-mod-gil-slot [0] modulo new race conditions where the code relied on the GIL for correctness, something which isn't strictly correct and can already break when the scheduler logic changes
- crabbone 3y ago
  > currently you can't do it at all Is not true. First of all, Python threads are mapped to OS threads. So, you can do "something". Now, in CPython C API there are tools for releasing and acquiring the global lock. They aren't complicated, and I used them in my own extensions. Not sure how popular across other extensions is this practice, but, at least some do use it. Some Python native functions release and acquire this lock while running in non-main thread. For the most part, it's the functions that perform blocking I/O. To sum this up and to make it easier to conceptualize, I describe this as Python can sleep concurrently, but can do no work concurrently. As to "obscure multithreading cases"... well, ironically, some Python libraries use Python threads unironically... I believe Paramico uses them, but this is from memory, so please don't blame me if that's not the case. It's not very popular, but some have actually used threads. Typically it gives you no benefits when using Python, but on an odd day... There's also a thing about when Python threads can switch, which makes certain code impossible to race, but also makes some particular edge cases of errors harder to reproduce. So, developers working on libraries that don't use any multithreading will probably not notice, but, these cases are rare because Python is on the path of dependency bloat. Which means that in a large enough project, you are bound to get a library that uses threads. And then you will be impacted by the bugs in multithreading even though you, personally, had nothing to do with it.
Jtsummers 3y ago
That discussion was amusing. Removing the GIL opens up the possibility of actually getting a real performance benefit from multithreaded Python code. That's the value. Given every modern desktop and server is multicore (and increasingly getting to tens of cores if not hundreds), multithreading in Python unhampered by the GIL will be a useful thing. And no, multiprocessing is not a good alternative to multithreading. It's just an alternative, but it's slower, uses more memory, and coordination between processes is slower than between threads.
- amomchilov 3y ago
  Heck, even my watch is dual-core. Now i doubt I’ll be writing Python for it any time soon, but to call multithreading obscure is… really odd.
- zarzavat 3y ago
  Python is not a language for writing fast code. Python is a relaxed language for things that don’t have to be fast. If you need something to be fast you are supposed to use a C extension and control it with Python - that’s been the dogma for as long as I can remember to avoid exactly this kind of pathological race to performance in a language that was never designed for it. By using Python you are already leaving a ton of performance on the table in single-threaded code compared to a fast, compiled language.
  - deleted 3y ago
    [deleted]
  - tgv 3y ago
    Yup. I don't know why you would insist on having multiple Python threads, especially given the high risks. Python is only suitable for coordinating/scripting large libraries written in other languages or for quick and easy development. Python programs should not reach the stage where their use in production is hampered by lack of multi-threading.
  - gjulianm 3y ago
    It's always a tradeoff, but I'm surprised to see so many people say that just because Python isn't fast it shouldn't get multithreading. Yes, by using Python we leave a lot of performance on the table. We also get a lot of dev performance, just because of the amount of libraries available, dynamic language features, quick development.. So it's not always a clear decision between Python or a compiled language. > If you need something to be fast you are supposed to use a C extension and control it with Python So what do we do with the case where we need to control the C extension from multiple threads? Because that's currently my problem. The C extension we developed do release the GIL, but because the Python code that does the calls to the extension can't be really multithreaded, the performance gain we get is minimal.
oivey 3y ago
That was the opinion of a handful of vocal posters. The overhead of using multiprocessing and/or some network service is extremely high for a lot of applications.
csmpltn 3y ago
There are plenty of other Python VMs that don't have a GIL and can be used already today, out of the box (examples include Jython and IronPython). Despite that fact - CPython remains the most popular Python VM out there (it utilizes a GIL). Instead of waiting for the GIL to be removed out of CPython - take your fancy Python code and just run it using a different VM. It's literally as simple as that. If the GIL was such a bottleneck as people make it out to be - people would move off of CPython a long time ago. But they won't, despite having the options. This only serves to prove that 95%+ of the workflows people build with Python can be satisfied regardless of GIL, often using some of the other parallelism mechanisms available in Python today (multiprocessing, asyncio, etc). Most of the stuff people build with Python are CRUD apps, Jupyter notebooks, automations, tinkering, small hacks, etc. If you're okay with not utilizing all of your 64k CPUs at home - Python's multiprocessing and asyncio libraries should serve you just fine. The whole GIL/No-GIL conversation is a complete waste of time and a distraction. People have all the options they need already here and now - but slinging crap at eachother over an issue tracker is so much fun that people can't help it.
- actionfromafar 3y ago
  If you have a lot of code, there’s plenty of Internet drama to be had in moving to another runtime, too.
- oivey 3y ago
  People stay on CPython due to the performance of C extensions and the vast ecosystem based on them. The fact that people have stuck with CPython isn't at all evidence that they like the GIL or that it doesn't lead to significant technical problems. Besides the C extension issue, Jython is based on Python 2.7 and IronPython appears to be on 3.4. These aren't serious alternatives.
  - sideeffffect 3y ago
    Not true. They're is GraalPython, which is for Python 3 and supports also native code extensions. https://github.com/oracle/graalpython https://github.com/oracle/graalpython
Spivak 3y ago
Right now multi-threading makes your Python code (that isn't really C) slower. The only real use of it is time slicing so you don't starve more important code like the web server or UI thread. You still have all the concurrency issues because your threads can still still be paused and resumed at arbitrary times. It does allow some operations in Python to be atomic but I, maybe naively, assume that those cases will be guarded by new, not whole interpreter, locks. With no-gil your multithreading code can, with no change to your code, take advantage of multiple cores and actually speed up your program. If
deleted 3y ago
[deleted]
qbasic_forever 3y ago
Correct, it will help with CPU-limited, embarrassingly parallelizable problems... which are much less common than you think.
- Nursie 3y ago
  You don’t need embarrassingly parallel problems, you just need code doing lots of the same thing at the same time for this to be a win.
- klyrs 3y ago
  Embarrassingly parallelizable problems are extremely common in my life. I end up breaking out of python to use gnu-parallel, which is fine but annoying.
  - slt2021 3y ago
    why? gnu parallel is strictly more inferior to multiprocessing module
ActorNightly 3y ago
The big thing that is driving no GIL is the speed up of processing data for ML, which afaik cannot be done with multiprocessing.

From reading the thread on HN the other day, it sounds like removing the GIL isn't really of much value. Maybe for somewhat obscure multithreading cases. Is that right?

FartyMcFarter 3y ago

I would disagree with that. The GIL means you can't use Python multithreading in order to take advantage of more CPU time by parallelism. Obviously getting rid of the GIL makes that a real option, just as it is in other languages.

squeaky-clean 3y ago

Currently, yes that's kind of true. But it's really only considered obscure because the GIL makes it so you either have to do some weird non thread pattern or go with a different language, and people often go with a different language. Kind of a Catch-22 of "Well no one uses it that way, so why should we make it possible to use it that way? Well, no one uses it that way because it's impossible to use it that way"

kukkamario 3y ago

Well Python doesn't really do proper multi-threading currently thanks to GIL blocking any additional execution threads. So removing it would enable making Python code that is actually multi-threaded without resorting to extra processes and their overhead. So if you are writing small single process Python script then removing GIL shouldn't really change much. If you are doing some heavier computing or eg. running server back-end, then there are significant performance gains available with this change.

School-Cotton 3y ago
You don’t have to use separate processes to get the benefit of multithreading in Python today — you can also call into a library written in native code that drops the GIL (e.g. Numpy or Pytorch).
- masklinn 3y ago
  Even then the GIL can cause issues, concerns of PyTorch are specifically one of the motivations of the PEP, and one of the reasons Meta / FB really really wants this: > In PyTorch, Python is commonly used to orchestrate ~8 GPUs and ~64 CPU threads, growing to 4k GPUs and 32k CPU threads for big models. While the heavy lifting is done outside of Python, the speed of GPUs makes even just the orchestration in Python not scalable. We often end up with 72 processes in place of one because of the GIL. Logging, debugging, and performance tuning are orders-of-magnitude more difficult in this regime, continuously causing lower developer productivity.
  - School-Cotton 3y ago
    I feel like orchestrating thousands of GPUs is such a niche use case that it’s fair to expect the people wanting to do it to learn a more suited language, rather than ruining Python for everyone else.
    - tgv 3y ago
      You are completely right. Why don't they write their stuff in another language? They've got the resources. Now the rest of the world will suffer the consequences, one of which may be that the devs of native libs will simply abandon the work, or that those libs will become too difficult to use for the casual or starting programmer, completely defeating the purpose. I'm fine with two builds, but not a single non-GIL build.
      - masklinn 3y ago
        > Now the rest of the world will suffer the consequences, one of which may be that the devs of native libs will simply abandon the work, or that those libs will become too difficult to use for the casual or starting programmer, completely defeating the purpose. Or get the benefits, so casual or starting programmers won't be wondering why their python program refuses to go above 100% CPU, or have to deal with the bullshit of multiprocessing. > I'm fine with two builds, but not a single non-GIL build. The "no-GIL" build has GIL machinery included, it just runs with the GIL disabled by default. You can force it on (https://peps.python.org/pep-0703/#pythongil-environment-variable https://peps.python.org/pep-0703/#pythongil-environment-vari...), and it will automatically enable itself when loading a non-no-gil library (https://peps.python.org/pep-0703/#py-mod-gil-slot https://peps.python.org/pep-0703/#py-mod-gil-slot).

masklinn 3y ago

> Maybe for somewhat obscure multithreading cases. They're only "somewhat obscure" because currently you can't do it at all, so you don't do it and you do something else: it's of value for any case where you're multithreading for computational parallelism (as opposed to IO concurrency). The PEP also outlines a bunch of other situations where using process-based parallelism is problematic: https://peps.python.org/pep-0703/#motivation https://peps.python.org/pep-0703/#motivation With the proviso that while it will work for all pure-python code out of the box[0] loading any native package which has not opted into "no gil" mode will re-enable the GIL: https://peps.python.org/pep-0703/#py-mod-gil-slot https://peps.python.org/pep-0703/#py-mod-gil-slot [0] modulo new race conditions where the code relied on the GIL for correctness, something which isn't strictly correct and can already break when the scheduler logic changes

crabbone 3y ago
> currently you can't do it at all Is not true. First of all, Python threads are mapped to OS threads. So, you can do "something". Now, in CPython C API there are tools for releasing and acquiring the global lock. They aren't complicated, and I used them in my own extensions. Not sure how popular across other extensions is this practice, but, at least some do use it. Some Python native functions release and acquire this lock while running in non-main thread. For the most part, it's the functions that perform blocking I/O. To sum this up and to make it easier to conceptualize, I describe this as Python can sleep concurrently, but can do no work concurrently. As to "obscure multithreading cases"... well, ironically, some Python libraries use Python threads unironically... I believe Paramico uses them, but this is from memory, so please don't blame me if that's not the case. It's not very popular, but some have actually used threads. Typically it gives you no benefits when using Python, but on an odd day... There's also a thing about when Python threads can switch, which makes certain code impossible to race, but also makes some particular edge cases of errors harder to reproduce. So, developers working on libraries that don't use any multithreading will probably not notice, but, these cases are rare because Python is on the path of dependency bloat. Which means that in a large enough project, you are bound to get a library that uses threads. And then you will be impacted by the bugs in multithreading even though you, personally, had nothing to do with it.

Jtsummers 3y ago

That discussion was amusing. Removing the GIL opens up the possibility of actually getting a real performance benefit from multithreaded Python code. That's the value. Given every modern desktop and server is multicore (and increasingly getting to tens of cores if not hundreds), multithreading in Python unhampered by the GIL will be a useful thing. And no, multiprocessing is not a good alternative to multithreading. It's just an alternative, but it's slower, uses more memory, and coordination between processes is slower than between threads.

amomchilov 3y ago
Heck, even my watch is dual-core. Now i doubt I’ll be writing Python for it any time soon, but to call multithreading obscure is… really odd.
zarzavat 3y ago
Python is not a language for writing fast code. Python is a relaxed language for things that don’t have to be fast. If you need something to be fast you are supposed to use a C extension and control it with Python - that’s been the dogma for as long as I can remember to avoid exactly this kind of pathological race to performance in a language that was never designed for it. By using Python you are already leaving a ton of performance on the table in single-threaded code compared to a fast, compiled language.
- deleted 3y ago
  [deleted]
- tgv 3y ago
  Yup. I don't know why you would insist on having multiple Python threads, especially given the high risks. Python is only suitable for coordinating/scripting large libraries written in other languages or for quick and easy development. Python programs should not reach the stage where their use in production is hampered by lack of multi-threading.
- gjulianm 3y ago
  It's always a tradeoff, but I'm surprised to see so many people say that just because Python isn't fast it shouldn't get multithreading. Yes, by using Python we leave a lot of performance on the table. We also get a lot of dev performance, just because of the amount of libraries available, dynamic language features, quick development.. So it's not always a clear decision between Python or a compiled language. > If you need something to be fast you are supposed to use a C extension and control it with Python So what do we do with the case where we need to control the C extension from multiple threads? Because that's currently my problem. The C extension we developed do release the GIL, but because the Python code that does the calls to the extension can't be really multithreaded, the performance gain we get is minimal.

oivey 3y ago

That was the opinion of a handful of vocal posters. The overhead of using multiprocessing and/or some network service is extremely high for a lot of applications.

csmpltn 3y ago

There are plenty of other Python VMs that don't have a GIL and can be used already today, out of the box (examples include Jython and IronPython). Despite that fact - CPython remains the most popular Python VM out there (it utilizes a GIL). Instead of waiting for the GIL to be removed out of CPython - take your fancy Python code and just run it using a different VM. It's literally as simple as that. If the GIL was such a bottleneck as people make it out to be - people would move off of CPython a long time ago. But they won't, despite having the options. This only serves to prove that 95%+ of the workflows people build with Python can be satisfied regardless of GIL, often using some of the other parallelism mechanisms available in Python today (multiprocessing, asyncio, etc). Most of the stuff people build with Python are CRUD apps, Jupyter notebooks, automations, tinkering, small hacks, etc. If you're okay with not utilizing all of your 64k CPUs at home - Python's multiprocessing and asyncio libraries should serve you just fine. The whole GIL/No-GIL conversation is a complete waste of time and a distraction. People have all the options they need already here and now - but slinging crap at eachother over an issue tracker is so much fun that people can't help it.

actionfromafar 3y ago
If you have a lot of code, there’s plenty of Internet drama to be had in moving to another runtime, too.
oivey 3y ago
People stay on CPython due to the performance of C extensions and the vast ecosystem based on them. The fact that people have stuck with CPython isn't at all evidence that they like the GIL or that it doesn't lead to significant technical problems. Besides the C extension issue, Jython is based on Python 2.7 and IronPython appears to be on 3.4. These aren't serious alternatives.
- sideeffffect 3y ago
  Not true. They're is GraalPython, which is for Python 3 and supports also native code extensions. https://github.com/oracle/graalpython https://github.com/oracle/graalpython

Spivak 3y ago

Right now multi-threading makes your Python code (that isn't really C) slower. The only real use of it is time slicing so you don't starve more important code like the web server or UI thread. You still have all the concurrency issues because your threads can still still be paused and resumed at arbitrary times. It does allow some operations in Python to be atomic but I, maybe naively, assume that those cases will be guarded by new, not whole interpreter, locks. With no-gil your multithreading code can, with no change to your code, take advantage of multiple cores and actually speed up your program. If

deleted 3y ago

[deleted]

qbasic_forever 3y ago

Correct, it will help with CPU-limited, embarrassingly parallelizable problems... which are much less common than you think.

Nursie 3y ago
You don’t need embarrassingly parallel problems, you just need code doing lots of the same thing at the same time for this to be a win.
klyrs 3y ago
Embarrassingly parallelizable problems are extremely common in my life. I end up breaking out of python to use gnu-parallel, which is fine but annoying.
- slt2021 3y ago
  why? gnu parallel is strictly more inferior to multiprocessing module

ActorNightly 3y ago

The big thing that is driving no GIL is the speed up of processing data for ML, which afaik cannot be done with multiprocessing.