10 ms·
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
by 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 agoThat 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 agoI 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.