5 ms·

I hope Sam Gross's no-GIL changes are adopted. It would be amazing to have full multithreaded concurrency in python. https://mail.python.org/archives/list/pyth

I hope Sam Gross's no-GIL changes are adopted. It would be amazing to have full multithreaded concurrency in python. https://mail.python.org/archives/list/python-dev@python.org/thread/ABR2L6BENNA6UPSPKV474HCS4LWT26GY/ https://mail.python.org/archives/list/python-dev@python.org/...

bratao 4y ago
I really wish this project didn't die, this would open to so many use-cases. I hate to use multi-process to scale my projects.
- matsemann 4y ago
  Yeah, while it in some regards is nice having multiple small deployments of our python app than can be scaled up and down independently, it's sometimes such an hurdle to something "extra" in a smaller app. Have a simple webserver and want to do some things out of band? In jvm I would use a concurrent queue and add tasks to it, and spin up some threads consuming that. In python you either spin up a new process and deal with the communication problems, become a master of greenlet and python internals, or most likely default to celery which need it's own deployment. It sometimes boggles my mind how python is considered the quick and easy way for startups, while at the same time doing trivial things become such a hurdle.
  - ledauphin 4y ago
    it's a huge hurdle in any scenario where you have large, static dataset from which you want to derive computation-heavy results. Multiprocessing generally requires making copies of that data, which can be impossible. The workarounds (e.g. mmap) take an order of magnitude more engineering effort.
    - dekhn 4y ago
      I agree 100% (I come from a "use all the cores with threads and shared memory to get linear speedups on many workloads" world). But I think at this point the python leadership has committed to the "every time the GIL-removal looks plausible, find some more single-core speedups to stave off the change". Put another way: I've given up on the hope that python will ever multicore the way I think it should multicore.
      - throwaway894345 4y ago
        I'd be tickled if Python would singlecore the way I think it should singlecore. Unfortunately, it remains considerably slower even than JavaScript (never mind Go, Java, etc). A lot of bad choices that can't easily be undone without breaking compatibility for a handful of packages, and the Python leadership seems unable or unwilling to guide the community through those changes.
    - onox 4y ago
      I had a similar problem last month where I needed to compute some results on multiple datasets (with a little bit of concurrency per dataset). In the end I just ported the code to Ada which makes it very easy to create task hierarchies. You can define variables of task types on the 'stack' and the program leaves the enclosing block when the variables can go out of scope after every task has finished. I can now easily put all cores to maximum use. The list comprehensions in Python became a little bit more verbose though because I had to use an older revision (2012) instead of the new 2022 revision.
    - d0mine 4y ago
      SharedMemory is a part of the multiprocessing module
    - orm 4y ago
      Have you checked out the Ray library? I use it for this type of scenario and it works well, without as much effort as it would take otherwise.
  - throwaway894345 4y ago
    > Have a simple webserver and want to do some things out of band? In jvm I would use a concurrent queue and add tasks to it, and spin up some threads consuming that. In python you either spin up a new process and deal with the communication problems, become a master of greenlet and python internals, or most likely default to celery which need it's own deployment. This is probably risky in production anyway, because the load balancer (typically) has no insight into these background tasks and will happily kill a process/pod/etc that is running a background process. You should probably dispatch the workload to an external task runner (e.g., Lambda or a Kubernetes Job or similar) unless you really don't care if the background task gets killed mid-flight. (I've had a few dev teams ignore these warnings and then blame infrastructure when their background jobs got killed mid-flight occasionally).
    - matsemann 4y ago
      Yes, that is true. My case here was about pushing some metrics somewhere, where losing some weren't an issue, but I didn't want to block main thread doing it. But this single java app on some EC2 instance could do what you need 10 "apps" and possibly a complicated k8s deployment to handle with python. Some just because the raw performance of python is far worse, but most of it because of cases like this, where simple things can't be shared. So lots of unnecessary complexity compared to "old and verbose" java. Another example is prometheus metrics. The current app I'm working on doesn't have a webserver. Which makes it really awkward in python to add prometheus. Since adding an endpoint to my app creates a new process and needs to be deployed almost as a sidecart, there is no smooth way to actually get the metrics from my main app to the endpoint that can be scraped since they don't share the same process.
btown 4y ago
Quick link to the (incredible) design doc linked in the first post there: https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsDFosB5e6BfnXLlejd9l0/edit# https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsD...
skrause 4y ago
Latest update about this project: https://pyfound.blogspot.com/2022/05/the-2022-python-language-summit-python_11.html https://pyfound.blogspot.com/2022/05/the-2022-python-languag... And the HN discussion: https://news.ycombinator.com/item?id=31348097 https://news.ycombinator.com/item?id=31348097
albertzeyer 4y ago
https://news.ycombinator.com/item?id=28880782 https://news.ycombinator.com/item?id=28880782 https://news.ycombinator.com/item?id=29005573 https://news.ycombinator.com/item?id=29005573 https://news.ycombinator.com/item?id=31348097 https://news.ycombinator.com/item?id=31348097 Note that Sam's no-GIL changes are not only about the removal of the GIL (although that was the main goal). There are a number of other unrelated improvements to make it faster. And as far as I know, most of those unrelated improvements have gotten into CPython now.
- rat87 4y ago
  I'm worried about it. My understanding is that the GIL removal was still slower then with GIL, but that he added useful unrelated speedups to compensate. If the speedups get into 3.11 but no gil doesn't will they accept a significantly slower 3.12?
  - jacob019 4y ago
    It might make sense to have runtime configuration that enables no-GIL mode, or just enable it automatically when importing threading, so that non-threaded workloads don't suffer.
  - __d 4y ago
    Yeah, I'm worried too. It seems like the core team doesn't share my sense that nogil is the single most important thing that Python needs to do in a world of many-core processors. If nogil is now blocked because it's deemed an unacceptable performance hit vs 3.11, I'll be very, very disappointed.
    - O5vYtytb 4y ago
      Most python code in the world is currently single threaded. It makes sense to me to start with the low hanging fruit that affects the majority of existing code and then move on to harder problems.
      - 4y ago

bratao 4y ago

I really wish this project didn't die, this would open to so many use-cases. I hate to use multi-process to scale my projects.

matsemann 4y ago
Yeah, while it in some regards is nice having multiple small deployments of our python app than can be scaled up and down independently, it's sometimes such an hurdle to something "extra" in a smaller app. Have a simple webserver and want to do some things out of band? In jvm I would use a concurrent queue and add tasks to it, and spin up some threads consuming that. In python you either spin up a new process and deal with the communication problems, become a master of greenlet and python internals, or most likely default to celery which need it's own deployment. It sometimes boggles my mind how python is considered the quick and easy way for startups, while at the same time doing trivial things become such a hurdle.
- ledauphin 4y ago
  it's a huge hurdle in any scenario where you have large, static dataset from which you want to derive computation-heavy results. Multiprocessing generally requires making copies of that data, which can be impossible. The workarounds (e.g. mmap) take an order of magnitude more engineering effort.
  - dekhn 4y ago
    I agree 100% (I come from a "use all the cores with threads and shared memory to get linear speedups on many workloads" world). But I think at this point the python leadership has committed to the "every time the GIL-removal looks plausible, find some more single-core speedups to stave off the change". Put another way: I've given up on the hope that python will ever multicore the way I think it should multicore.
    - throwaway894345 4y ago
      I'd be tickled if Python would singlecore the way I think it should singlecore. Unfortunately, it remains considerably slower even than JavaScript (never mind Go, Java, etc). A lot of bad choices that can't easily be undone without breaking compatibility for a handful of packages, and the Python leadership seems unable or unwilling to guide the community through those changes.
  - onox 4y ago
    I had a similar problem last month where I needed to compute some results on multiple datasets (with a little bit of concurrency per dataset). In the end I just ported the code to Ada which makes it very easy to create task hierarchies. You can define variables of task types on the 'stack' and the program leaves the enclosing block when the variables can go out of scope after every task has finished. I can now easily put all cores to maximum use. The list comprehensions in Python became a little bit more verbose though because I had to use an older revision (2012) instead of the new 2022 revision.
  - d0mine 4y ago
    SharedMemory is a part of the multiprocessing module
  - orm 4y ago
    Have you checked out the Ray library? I use it for this type of scenario and it works well, without as much effort as it would take otherwise.
- throwaway894345 4y ago
  > Have a simple webserver and want to do some things out of band? In jvm I would use a concurrent queue and add tasks to it, and spin up some threads consuming that. In python you either spin up a new process and deal with the communication problems, become a master of greenlet and python internals, or most likely default to celery which need it's own deployment. This is probably risky in production anyway, because the load balancer (typically) has no insight into these background tasks and will happily kill a process/pod/etc that is running a background process. You should probably dispatch the workload to an external task runner (e.g., Lambda or a Kubernetes Job or similar) unless you really don't care if the background task gets killed mid-flight. (I've had a few dev teams ignore these warnings and then blame infrastructure when their background jobs got killed mid-flight occasionally).
  - matsemann 4y ago
    Yes, that is true. My case here was about pushing some metrics somewhere, where losing some weren't an issue, but I didn't want to block main thread doing it. But this single java app on some EC2 instance could do what you need 10 "apps" and possibly a complicated k8s deployment to handle with python. Some just because the raw performance of python is far worse, but most of it because of cases like this, where simple things can't be shared. So lots of unnecessary complexity compared to "old and verbose" java. Another example is prometheus metrics. The current app I'm working on doesn't have a webserver. Which makes it really awkward in python to add prometheus. Since adding an endpoint to my app creates a new process and needs to be deployed almost as a sidecart, there is no smooth way to actually get the metrics from my main app to the endpoint that can be scraped since they don't share the same process.

btown 4y ago

Quick link to the (incredible) design doc linked in the first post there: https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsDFosB5e6BfnXLlejd9l0/edit# https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsD...

skrause 4y ago

Latest update about this project: https://pyfound.blogspot.com/2022/05/the-2022-python-language-summit-python_11.html https://pyfound.blogspot.com/2022/05/the-2022-python-languag... And the HN discussion: https://news.ycombinator.com/item?id=31348097 https://news.ycombinator.com/item?id=31348097

albertzeyer 4y ago

https://news.ycombinator.com/item?id=28880782 https://news.ycombinator.com/item?id=28880782 https://news.ycombinator.com/item?id=29005573 https://news.ycombinator.com/item?id=29005573 https://news.ycombinator.com/item?id=31348097 https://news.ycombinator.com/item?id=31348097 Note that Sam's no-GIL changes are not only about the removal of the GIL (although that was the main goal). There are a number of other unrelated improvements to make it faster. And as far as I know, most of those unrelated improvements have gotten into CPython now.

rat87 4y ago
I'm worried about it. My understanding is that the GIL removal was still slower then with GIL, but that he added useful unrelated speedups to compensate. If the speedups get into 3.11 but no gil doesn't will they accept a significantly slower 3.12?
- jacob019 4y ago
  It might make sense to have runtime configuration that enables no-GIL mode, or just enable it automatically when importing threading, so that non-threaded workloads don't suffer.
- __d 4y ago
  Yeah, I'm worried too. It seems like the core team doesn't share my sense that nogil is the single most important thing that Python needs to do in a world of many-core processors. If nogil is now blocked because it's deemed an unacceptable performance hit vs 3.11, I'll be very, very disappointed.
  - O5vYtytb 4y ago
    Most python code in the world is currently single threaded. It makes sense to me to start with the low hanging fruit that affects the majority of existing code and then move on to harder problems.
    - 4y ago