6 ms·

> It's "free" in the sense that you don't need to re-write large parts of the VM In that sense, never updating python again is "free" as well, because it would

> It's "free" in the sense that you don't need to re-write large parts of the VM In that sense, never updating python again is "free" as well, because it would save the python devs the trouble of changing the interpreter. And yet I think we can all agree that Python benefits from the fact that we no longer use Python 3.5 > and teach the entire Python community how to safely write multi-threaded code People who don't write threaded code don't need to worry about it. And people who write threaded code in python already need to worry about writing thread-safe code. The GIL doesn't prevent race conditions between individual python instructions. > Python has the means to do that already And as outlined above, these means are no suitable replacement for true thread based parallelism.

csmpltn 3y ago
> "And as outlined above, these means are no suitable replacement for true thread based parallelism." Your only argument is that "thread-based parallelism can't be achieved without threads", but that's not relevant to the conversation whatsoever. The fact of the matter is that Python (already today) allows you to achieve parallelism across both IO-bound and CPU-bound workloads. For CPU-bound workloads, the number of threads you can run in parallel is bound by the number of cores you have. For IO-bound workloads, your threads are just waiting on interrupts. What are concrete use-cases where thread-based parallelism in Python is so desperately needed right now, that can't be achieved through process-based parallelism? I'll give you one: real-time latency/throughput-sensitive DSP. Think real-time audio processing, or real-time algorithmic trading. Python isn't used there to begin with (for an entire flurry of reasons) - GIL or no GIL.
- usrbinbash 3y ago
  > The fact of the matter is that Python (already today) allows you to achieve parallelism across both IO-bound and CPU-bound workloads. I also don't need to use goroutines. I could simply spin up my golang application as a couple of processes, and use pipes and other IPC to coordinate them. "There is another way to do X" doesn't imply that other way is better.
  - csmpltn 3y ago
    > "doesn't imply that other way is better" I never said that multiprocessing is "better" than multithreading. Both are mechanisms to achieve parallelism with different pros/cons, and there are legit cases where threads are a necessity that can't be satisfied with processes (ref my previous comment with examples). This conversation would've been much easier to have given specific constraints and examples (which nobody seems to give). Within the context of a general purpose VM which was never built to support multithreading (CPython), and which carries the baggage of 30+ years' worth of 3rd-party packages and libraries which were never built with multithreading in-mind - I think we can both agree that the costs and risks of changing literally everything may outweigh the benefits. It's not a difficult stance to accept. My main argument, if you distill it down to the abstract, is "use the right tool for the job" - and stop pretending that a hammer and a knife are the same thing, when they're not. If you need hardcore, ultra efficient and parallelized workflows - Python is just the wrong tool for the job period. This isn't up for debate - it's a given fact. This isn't just about the GIL - it's about the type system, the frameworks, the bloat, etc. There's nothing wrong with Python being this way - Python fills a niche of its own incredibly well, something which others tools suck at, and Python is loved by millions for it. Python is used today by certain demographics to perform certain jobs - and it excels really well at those jobs for those demographics. This whole discussion now (GIL vs. no GIL) is about bending and twisting Python to fit the use cases of few companies like DeepMind or Facebook - who I'm certain represent a miniscule usage compared to the millions of students, schools and universities, research institutes, web shops, hobbyists, tinkerers, etc. Those people want to get shit done quickly - and mutexes, sempahores, events, threads, synchronization primitives, atomics, etc - will do nothing but make their lives a misery, and drive them away. Also, I keep asking you for concrete examples where the Python community absolutely needs multithreading (where multiprocessing fails) and you're not really responding which makes me feel like we're not conversing here...
    - commonlisp94 3y ago
      I completely agree with this position. If you need an optimized paralyzed code to chew through a tough workload, write that part in C, and spawn it from python. Python is a coordinating scripting language.
miraculixx 3y ago
Progress in the name if progress is rarely a good choice. The key question that remains unanswered is Why should Python even need a free threading model? There are no good answers afaik.
- usrbinbash 3y ago
  > There are no good answers afaik. I shall be more than happy to provide them: Supporting thread based parallelism is the norm among all mainstream PLs with the one inglorious exception of JS, which doesn't because it simply can't. And Python already does support it, it simply is limited by a legacy design decision. That was okay in a bygone age when fast single core machines were still the norm, Python was primarily a scripting language for when bash wasn't enough, and most relevant webapps were IO bound. Today, there simply is no excuse any more. Python is the most ubiquitous language in the world, and running scaling web applications, is the lingua franca of ML, and orchestrates huge systems. Servers have hundreds of cores, and CPU bound workloads become ever more important. It's about time Python rids itself of that needless limitation.
  - commonlisp94 3y ago
    > because it simply can't. It can't for the same reason python can't - every part was designed without it in mind. > Python already does support it The language runtime might have it in a branch, but the vast majority of C code it is based on, and the scripts themselves assume otherwise. > fast single core machines Once again, if you are using python as a scripting language, with C libraries, and spawning processes, you are already utilizing multiple cores without any adjustment on your part. > CPU bound workloads become ever more important. If that's true, then you shouldn't use python. It's about 100x slower than C. How much performance can you squeeze out of dividing work into cooperating threads, that can't be easily achieved by having multiple processes. In the "web application" example you are using, the norm is already to have many processes to handle incoming connections.
    - usrbinbash 3y ago
      > every part was designed without it in mind. Interesting, care to explain then why Python supported threading since Python2? [1] > Once again, if you are using python as a scripting language > If that's true, then you shouldn't use python. Once again, I don't. I use it as an orchestration language calling other code, and there is no good reason why the orchestration language should have an arbitrary bottleneck. Yes, the hot code isn't written in Python. That doesn't matter to this discussion. > In the "web application" example you are using, the norm is already to have many processes to handle incoming connections. Outside of the python world, it absolutely isn't. I also have numerous Go based webservices, and they don't have to jump through ICP hoops to facilitate communications between workers and services. [1]: https://docs.python.org/2/library/threading.html https://docs.python.org/2/library/threading.html
miraculixx 3y ago
> The GIL doesn't prevent race conditions between individual python instructions Yes it does. Unless we mean something different?
- usrbinbash 3y ago
  > Yes it does. No, it doesn't. def thread_function(): # thread may lose core here value = store.get_value() # or anywhere inside get_value # or here update(value) # or anywhere inside update() # or here store.put_value(value) # or anywhere inside put_value() The GIL only makes certain internal functionality atomic. It doesn't protect the implemented logic from causing a race condition. So unless I protect store with a lock, I can already get a race condition, GIL or no GIL.
  - csmpltn 3y ago
    The user you're replying to is saying that the GIL is preventing multiple threads from executing Python bytecodes at once (preventing some classes of race conditions and ensuring thread safety). They are absolutely correct. The GIL doesn't solve or prevent all classes of race conditions (which can stem from complex interactions with databases, the filesystem, etc). Removing the GIL though, will only make things worse from that perspective - making the language more difficult to work with (for non-technical people). This is exactly why Python should be further simplified, and not made more complex - given the population which uses it most.
    - usrbinbash 3y ago
      > and not made more complex The changes to the GIL don't force the average user to write threading code.

csmpltn 3y ago

> "And as outlined above, these means are no suitable replacement for true thread based parallelism." Your only argument is that "thread-based parallelism can't be achieved without threads", but that's not relevant to the conversation whatsoever. The fact of the matter is that Python (already today) allows you to achieve parallelism across both IO-bound and CPU-bound workloads. For CPU-bound workloads, the number of threads you can run in parallel is bound by the number of cores you have. For IO-bound workloads, your threads are just waiting on interrupts. What are concrete use-cases where thread-based parallelism in Python is so desperately needed right now, that can't be achieved through process-based parallelism? I'll give you one: real-time latency/throughput-sensitive DSP. Think real-time audio processing, or real-time algorithmic trading. Python isn't used there to begin with (for an entire flurry of reasons) - GIL or no GIL.

usrbinbash 3y ago
> The fact of the matter is that Python (already today) allows you to achieve parallelism across both IO-bound and CPU-bound workloads. I also don't need to use goroutines. I could simply spin up my golang application as a couple of processes, and use pipes and other IPC to coordinate them. "There is another way to do X" doesn't imply that other way is better.
- csmpltn 3y ago
  > "doesn't imply that other way is better" I never said that multiprocessing is "better" than multithreading. Both are mechanisms to achieve parallelism with different pros/cons, and there are legit cases where threads are a necessity that can't be satisfied with processes (ref my previous comment with examples). This conversation would've been much easier to have given specific constraints and examples (which nobody seems to give). Within the context of a general purpose VM which was never built to support multithreading (CPython), and which carries the baggage of 30+ years' worth of 3rd-party packages and libraries which were never built with multithreading in-mind - I think we can both agree that the costs and risks of changing literally everything may outweigh the benefits. It's not a difficult stance to accept. My main argument, if you distill it down to the abstract, is "use the right tool for the job" - and stop pretending that a hammer and a knife are the same thing, when they're not. If you need hardcore, ultra efficient and parallelized workflows - Python is just the wrong tool for the job period. This isn't up for debate - it's a given fact. This isn't just about the GIL - it's about the type system, the frameworks, the bloat, etc. There's nothing wrong with Python being this way - Python fills a niche of its own incredibly well, something which others tools suck at, and Python is loved by millions for it. Python is used today by certain demographics to perform certain jobs - and it excels really well at those jobs for those demographics. This whole discussion now (GIL vs. no GIL) is about bending and twisting Python to fit the use cases of few companies like DeepMind or Facebook - who I'm certain represent a miniscule usage compared to the millions of students, schools and universities, research institutes, web shops, hobbyists, tinkerers, etc. Those people want to get shit done quickly - and mutexes, sempahores, events, threads, synchronization primitives, atomics, etc - will do nothing but make their lives a misery, and drive them away. Also, I keep asking you for concrete examples where the Python community absolutely needs multithreading (where multiprocessing fails) and you're not really responding which makes me feel like we're not conversing here...
  - commonlisp94 3y ago
    I completely agree with this position. If you need an optimized paralyzed code to chew through a tough workload, write that part in C, and spawn it from python. Python is a coordinating scripting language.

miraculixx 3y ago

Progress in the name if progress is rarely a good choice. The key question that remains unanswered is Why should Python even need a free threading model? There are no good answers afaik.

usrbinbash 3y ago
> There are no good answers afaik. I shall be more than happy to provide them: Supporting thread based parallelism is the norm among all mainstream PLs with the one inglorious exception of JS, which doesn't because it simply can't. And Python already does support it, it simply is limited by a legacy design decision. That was okay in a bygone age when fast single core machines were still the norm, Python was primarily a scripting language for when bash wasn't enough, and most relevant webapps were IO bound. Today, there simply is no excuse any more. Python is the most ubiquitous language in the world, and running scaling web applications, is the lingua franca of ML, and orchestrates huge systems. Servers have hundreds of cores, and CPU bound workloads become ever more important. It's about time Python rids itself of that needless limitation.
- commonlisp94 3y ago
  > because it simply can't. It can't for the same reason python can't - every part was designed without it in mind. > Python already does support it The language runtime might have it in a branch, but the vast majority of C code it is based on, and the scripts themselves assume otherwise. > fast single core machines Once again, if you are using python as a scripting language, with C libraries, and spawning processes, you are already utilizing multiple cores without any adjustment on your part. > CPU bound workloads become ever more important. If that's true, then you shouldn't use python. It's about 100x slower than C. How much performance can you squeeze out of dividing work into cooperating threads, that can't be easily achieved by having multiple processes. In the "web application" example you are using, the norm is already to have many processes to handle incoming connections.
  - usrbinbash 3y ago
    > every part was designed without it in mind. Interesting, care to explain then why Python supported threading since Python2? [1] > Once again, if you are using python as a scripting language > If that's true, then you shouldn't use python. Once again, I don't. I use it as an orchestration language calling other code, and there is no good reason why the orchestration language should have an arbitrary bottleneck. Yes, the hot code isn't written in Python. That doesn't matter to this discussion. > In the "web application" example you are using, the norm is already to have many processes to handle incoming connections. Outside of the python world, it absolutely isn't. I also have numerous Go based webservices, and they don't have to jump through ICP hoops to facilitate communications between workers and services. [1]: https://docs.python.org/2/library/threading.html https://docs.python.org/2/library/threading.html

miraculixx 3y ago

> The GIL doesn't prevent race conditions between individual python instructions Yes it does. Unless we mean something different?

usrbinbash 3y ago
> Yes it does. No, it doesn't. def thread_function(): # thread may lose core here value = store.get_value() # or anywhere inside get_value # or here update(value) # or anywhere inside update() # or here store.put_value(value) # or anywhere inside put_value() The GIL only makes certain internal functionality atomic. It doesn't protect the implemented logic from causing a race condition. So unless I protect store with a lock, I can already get a race condition, GIL or no GIL.
- csmpltn 3y ago
  The user you're replying to is saying that the GIL is preventing multiple threads from executing Python bytecodes at once (preventing some classes of race conditions and ensuring thread safety). They are absolutely correct. The GIL doesn't solve or prevent all classes of race conditions (which can stem from complex interactions with databases, the filesystem, etc). Removing the GIL though, will only make things worse from that perspective - making the language more difficult to work with (for non-technical people). This is exactly why Python should be further simplified, and not made more complex - given the population which uses it most.
  - usrbinbash 3y ago
    > and not made more complex The changes to the GIL don't force the average user to write threading code.