3 ms·

I guess I think of highly parallel CPU-bound work as being fundamentally against the ethos of Python, which is to be a scripting/glue language on top of native

I guess I think of highly parallel CPU-bound work as being fundamentally against the ethos of Python, which is to be a scripting/glue language on top of native extensions. Thus anything (like GIL removal) that makes it harder to write native extensions is harmful. Even if the GIL is removed, the task you’re talking about would be dozens of times slower in Python than in a better-suited language, so why not write it in C++ or Rust and then call into that from Python? I could be wrong or missing something, and I’m not a Python developer so I don’t really have a dog in the fight, but I just wanted to try to explain where some of the criticism is coming from.

w-m 3y ago
It's exactly the high-performance native extensions that require the GIL removal to allow for a full utilization of the machine. Although already successful as glue for these libraries, Python is ultimately hamstrung by the GIL on many-core machines. Using the GIL removal to start writing algorithms in interpreted Python is not the intention. I warmly recommend reading the motivation section of the PEP. It is incredibly well written, quoting issues from PyTorch, scikit and NumPy: https://peps.python.org/pep-0703/ https://peps.python.org/pep-0703/
- School-Cotton 3y ago
  That doesn't make sense to me, since native extensions can and do drop the GIL. Try calling `torch.set_num_threads(16)` and then doing some CPU-intensive operation on a large tensor; you will observe the Python process using 16 cores. What am I missing?
  - w-m 3y ago
    I think you are missing that the world is a little messy. You are correct that native extensions can and do drop the GIL. But data needs to be loaded, it needs to be preprocessed (does your image downsampling library drop the GIL? Does the video decoder drop the GIL? How do you find out? You need to do a little string processing on your data, well then you're out of luck.). Hardware devices need to be managed. Progress needs to be logged, and operations need to be debugged. There isn't a perfect kernel that can be run for every operation, you may have to run a little Python code before calling into your native code. Again, I would encourage you to read the motivation section of the PEP, which shows a multitude of frustrations with the current state. The issue is subtle enough that I'm struggling to summarize it in a single sentence.

w-m 3y ago

It's exactly the high-performance native extensions that require the GIL removal to allow for a full utilization of the machine. Although already successful as glue for these libraries, Python is ultimately hamstrung by the GIL on many-core machines. Using the GIL removal to start writing algorithms in interpreted Python is not the intention. I warmly recommend reading the motivation section of the PEP. It is incredibly well written, quoting issues from PyTorch, scikit and NumPy: https://peps.python.org/pep-0703/ https://peps.python.org/pep-0703/

School-Cotton 3y ago
That doesn't make sense to me, since native extensions can and do drop the GIL. Try calling `torch.set_num_threads(16)` and then doing some CPU-intensive operation on a large tensor; you will observe the Python process using 16 cores. What am I missing?
- w-m 3y ago
  I think you are missing that the world is a little messy. You are correct that native extensions can and do drop the GIL. But data needs to be loaded, it needs to be preprocessed (does your image downsampling library drop the GIL? Does the video decoder drop the GIL? How do you find out? You need to do a little string processing on your data, well then you're out of luck.). Hardware devices need to be managed. Progress needs to be logged, and operations need to be debugged. There isn't a perfect kernel that can be run for every operation, you may have to run a little Python code before calling into your native code. Again, I would encourage you to read the motivation section of the PEP, which shows a multitude of frustrations with the current state. The issue is subtle enough that I'm struggling to summarize it in a single sentence.