5 ms·

Multithreaded Python without the GIL is possible

26 points by xiaodai 5y ago

CogitoCogito 5y ago
> The purpose of this document and associated code is to convince you of a few things: > That it is feasible to remove the GIL from Python. > That the tradeoffs are manageable and the effort to remove the GIL is worthwhile. ... > Removing the GIL will require making trade-offs and taking on substantial risk: > Removing the GIL will be a large, multi-year undertaking with increased risk for introducing bugs and regressions. > Removing the GIL means making trade-offs between single and multi-threaded performance. I believe we can make a future CPython without the GIL that is faster for both single and multi-threaded workloads than current CPython, but if we keep the GIL and focus solely on single-threaded workloads, we would achieve even better single-threaded performance. (See the “Performance” section for more details.) I don't want to be too cynical (I am after all not critiquing the details), but this is basically how every remove the GIL project starts. many intelligent people have tried. Many have failed. There are just so many trade-offs, compatibility issues, etc. I'm not personally against this project, but really I'd rather read a document describing the successful result rather than outlining the goals. That said work on cpython that tries to clean up internal state has gone on for many years and is great. That sort of thing might make removing the GIL more reasonable in the future, but also makes the code easier to understand and work with in the present. Regardless of my negativity, I wish the author good luck!
- karmakaze 5y ago
  My view of this is that it's great that they haven't stopped trying just because others have failed. This is necessary for the long term future of Python as more and more computing becomes multi-core.
- bratao 5y ago
  I agree, but in this case they already made a functional and faster( with some unrelated optimizations) in single thread. This is the real deal!
- thehappypm 5y ago
  This is such terrible feedback IMO. "You will fail, because others have."
  - CogitoCogito 5y ago
    Nowhere did I say this approach will fail.

26 points by xiaodai 5y ago

> The purpose of this document and associated code is to convince you of a few things: > That it is feasible to remove the GIL from Python. > That the tradeoffs are manageable and the effort to remove the GIL is worthwhile. ... > Removing the GIL will require making trade-offs and taking on substantial risk: > Removing the GIL will be a large, multi-year undertaking with increased risk for introducing bugs and regressions. > Removing the GIL means making trade-offs between single and multi-threaded performance. I believe we can make a future CPython without the GIL that is faster for both single and multi-threaded workloads than current CPython, but if we keep the GIL and focus solely on single-threaded workloads, we would achieve even better single-threaded performance. (See the “Performance” section for more details.) I don't want to be too cynical (I am after all not critiquing the details), but this is basically how every remove the GIL project starts. many intelligent people have tried. Many have failed. There are just so many trade-offs, compatibility issues, etc. I'm not personally against this project, but really I'd rather read a document describing the successful result rather than outlining the goals. That said work on cpython that tries to clean up internal state has gone on for many years and is great. That sort of thing might make removing the GIL more reasonable in the future, but also makes the code easier to understand and work with in the present. Regardless of my negativity, I wish the author good luck!

karmakaze 5y ago
My view of this is that it's great that they haven't stopped trying just because others have failed. This is necessary for the long term future of Python as more and more computing becomes multi-core.
bratao 5y ago
I agree, but in this case they already made a functional and faster( with some unrelated optimizations) in single thread. This is the real deal!
thehappypm 5y ago
This is such terrible feedback IMO. "You will fail, because others have."
- CogitoCogito 5y ago
  Nowhere did I say this approach will fail.