3 ms·

My private opinion, but I think removing GIL is a mistake. Not that many applications will benefit strongly from this, most will suffer a performance penalty. T

My private opinion, but I think removing GIL is a mistake. Not that many applications will benefit strongly from this, most will suffer a performance penalty. This will take years of attention/effort which could be spent more wisely. It kind of seems like Python suffers from insecurity / inferiority complex about GIL. I would instead go with the "JavaScript route" of fully embracing the single thread model. Yes, some applications will remain hard / impossible, but I'd argue Python is not a good fit for apps requiring high performance / high scalability anyway. Being somewhat specialized and not supporting every use case isn't necessarily bad.

klodolph 3y ago
It may be too late to go with the JavaScript model.
- The_Colonel 3y ago
  Why?
  - klodolph 3y ago
    There’s a lot of deployed Python code that uses multithreading. The genie is out of the bottle, so to speak. The JavaScript model is, basically, the sub-interpreter model. You have multiple independent heaps. Given independent heaps, you write single-threaded code and don't worry about locking, because no other thread can modify objects in your heap anyway, outside of special objects like SharedArrayBuffer. Maybe you could enable GIL-free, single-threaded, sub-interpreter Python as a compile-time option. But it would break such a large amount of code out there. It would be a very difficult transition, practically speaking.
Znafon 3y ago
The PEP goes into details about the motivations and why the single thread model has limitations: https://peps.python.org/pep-0703/#motivation https://peps.python.org/pep-0703/#motivation. > Yes, some applications will remain hard / impossible, but I'd argue Python is not a good fit for apps requiring high performance / high scalability anyway People are already trying to use Python for parallel tasks. Forcing people to use another language does not help them much.
seanp2k2 3y ago
Supporting Unicode from the beginning probably would have been a good idea too but it is what it is. Happy to see them taking this on.
pmart123 3y ago
Always thought great JIT that's compatible with Cython and major projects with C extensions like numpy, scipy would be a more worthwhile effort. A lot of the data intensive tasks Python can be run in parallel processes easily so doesn't seem like a major benefit to removing the GIL?
electroly 3y ago
> not a good fit for apps requiring high performance / high scalability anyway It's way too late to artificially limit Python's reach like this. It's already heavily used in data science and machine learning. People need performance right now for things that they are already doing in Python. We can't go back to a time when that isn't true. Now it's one of the most common use cases for Python. People are building careers on this.
- KeplerBoy 3y ago
  Those people/use-cases don't care about the GIL. When you're doing anything numerical you're calling into Numpy, Pytorch or Polars anyways and those libraries make use of multiple threads and drop the GIL. So yes, you can do Matmuls to your heart's content in one python thread and wait for file i/o in another thread without ever running into issues with the GIL. I'd even say if your Python Interpreter isn't bored waiting for stuff to happen, you're doing it wrong.
  - shafte 3y ago
    > Those people/use-cases don't care about the GIL. This is not true. The primary funding and motivation for the GIL removal work comes from the numerical computing community. The PEP (https://peps.python.org/pep-0703/ https://peps.python.org/pep-0703/) contains direct quotes from folks working on numpy, scipy, PyTorch, scikit-learn, etc. and also practitioners from places like Meta, DeepMind and so on, describing the practical constraints that the GIL places on many workloads.
  - deleted 3y ago
    [deleted]
- jerf 3y ago
  This doesn't solve the data science and machine learning problems, though. You will still have the problem that optimized code paths will be hundreds to thousands to even millions of times faster (on a GPU) than any Python could be, and falling back to pure Python, accidentally or otherwise, will still incur those slowdowns, even if the resulting pure Python code is embarrassingly parallel and that is fully perfectly exploited. Personally, I wouldn't be surprised all this work gets done on GIL-removal, and the end result is that if you run 10 threads in Python you max out at roughly a 3x performance improvement in your pure Python code (and often get less, I do mean that as a max not an average), with all the memory traffic it is doing. Honestly even if it did perfectly parallelize up to 32 cores, a completely impossible absurdity, it would still be noticeably inferior performance to what many languages will give you on one core. I can't help but think that if you're sitting here waiting with bated breath for the GIL-ectomy to improve your Python performance that that is a sign you should be rewriting your code right now in any number of languages that are simply faster. I very, very strongly suspect that this is going to result in very very disappointing speedups when it is done.
lost_tourist 3y ago
In the age of common multi-processors(by over a decade)... it's time to embrace it. Especially if it comes with little or no cost thanks to great interpreter engineers. I will personally embrace it.

klodolph 3y ago

It may be too late to go with the JavaScript model.

The_Colonel 3y ago
Why?
- klodolph 3y ago
  There’s a lot of deployed Python code that uses multithreading. The genie is out of the bottle, so to speak. The JavaScript model is, basically, the sub-interpreter model. You have multiple independent heaps. Given independent heaps, you write single-threaded code and don't worry about locking, because no other thread can modify objects in your heap anyway, outside of special objects like SharedArrayBuffer. Maybe you could enable GIL-free, single-threaded, sub-interpreter Python as a compile-time option. But it would break such a large amount of code out there. It would be a very difficult transition, practically speaking.

Znafon 3y ago

The PEP goes into details about the motivations and why the single thread model has limitations: https://peps.python.org/pep-0703/#motivation https://peps.python.org/pep-0703/#motivation. > Yes, some applications will remain hard / impossible, but I'd argue Python is not a good fit for apps requiring high performance / high scalability anyway People are already trying to use Python for parallel tasks. Forcing people to use another language does not help them much.

seanp2k2 3y ago

Supporting Unicode from the beginning probably would have been a good idea too but it is what it is. Happy to see them taking this on.

pmart123 3y ago

Always thought great JIT that's compatible with Cython and major projects with C extensions like numpy, scipy would be a more worthwhile effort. A lot of the data intensive tasks Python can be run in parallel processes easily so doesn't seem like a major benefit to removing the GIL?

electroly 3y ago

> not a good fit for apps requiring high performance / high scalability anyway It's way too late to artificially limit Python's reach like this. It's already heavily used in data science and machine learning. People need performance right now for things that they are already doing in Python. We can't go back to a time when that isn't true. Now it's one of the most common use cases for Python. People are building careers on this.

KeplerBoy 3y ago
Those people/use-cases don't care about the GIL. When you're doing anything numerical you're calling into Numpy, Pytorch or Polars anyways and those libraries make use of multiple threads and drop the GIL. So yes, you can do Matmuls to your heart's content in one python thread and wait for file i/o in another thread without ever running into issues with the GIL. I'd even say if your Python Interpreter isn't bored waiting for stuff to happen, you're doing it wrong.
- shafte 3y ago
  > Those people/use-cases don't care about the GIL. This is not true. The primary funding and motivation for the GIL removal work comes from the numerical computing community. The PEP (https://peps.python.org/pep-0703/ https://peps.python.org/pep-0703/) contains direct quotes from folks working on numpy, scipy, PyTorch, scikit-learn, etc. and also practitioners from places like Meta, DeepMind and so on, describing the practical constraints that the GIL places on many workloads.
- deleted 3y ago
  [deleted]
jerf 3y ago
This doesn't solve the data science and machine learning problems, though. You will still have the problem that optimized code paths will be hundreds to thousands to even millions of times faster (on a GPU) than any Python could be, and falling back to pure Python, accidentally or otherwise, will still incur those slowdowns, even if the resulting pure Python code is embarrassingly parallel and that is fully perfectly exploited. Personally, I wouldn't be surprised all this work gets done on GIL-removal, and the end result is that if you run 10 threads in Python you max out at roughly a 3x performance improvement in your pure Python code (and often get less, I do mean that as a max not an average), with all the memory traffic it is doing. Honestly even if it did perfectly parallelize up to 32 cores, a completely impossible absurdity, it would still be noticeably inferior performance to what many languages will give you on one core. I can't help but think that if you're sitting here waiting with bated breath for the GIL-ectomy to improve your Python performance that that is a sign you should be rewriting your code right now in any number of languages that are simply faster. I very, very strongly suspect that this is going to result in very very disappointing speedups when it is done.

lost_tourist 3y ago

In the age of common multi-processors(by over a decade)... it's time to embrace it. Especially if it comes with little or no cost thanks to great interpreter engineers. I will personally embrace it.