5 ms·

It's good to see Python finally able to get rid of GIL. Looking forward to see how much performance can it improve.

fastball 2y ago
We already know the upper bound of perf improvement – existing perf * number of cores. It will be worse than that though, as all the GILectomy plans make single-threaded performance worse. So if you're expecting something better than that, you will be disappointed.
- vlovich123 2y ago
  All the GILectomy plans IIRC also include single threaded performance improvements to offset any such costs. So while performance vs GIL is maybe worse for single threaded for the same Python version, performance will still be ahead of where it is today for single-threaded python (assuming everything goes according to plan). That's also why multi-threaded performance will be more than just existing perf * number of cores (vs what it is today, not what removing the GIL alone provides).
  - eviks 2y ago
    But it doesn't offset anything since you get all the other improvements anyway, they're not tied to gil/nogil
    - vlovich123 2y ago
      I could be misremembering, but I thought that the MSFT team proposed those performance improvements specifically to offset any concerns about single threaded performance degradation from removing the GIL. Thus even if development is happening in parallel by independent (which I thought it wasn't - I thought it was all 1 team doing this work), it was predicated upon nogil being accepted in the first place. Thus if GIL were to remain in Python, then this performance work wouldn't be happening.
      - eviks 2y ago
        Maybe the work wouldn't be happening without the noGIL work, but once it's happened it's not tied to the GIL, you can pick those improvements and continue with a GIL-only Python
        vlovich123 2y ago
        This post is literally about step 1: add this behind an unsupported experimental flag to get more insights. Step 2 is mid-term to make it a supported option based on readiness (within another 2 years). Step 3 is making it the default & then removing the GIL [1]. Steps 2 and 3 may not happen if some major unsolvable obstacle appears. But I doubt it's going to be so easy to reverse this direction. Given MSFT is driving all of this right now, it's hard to imagine there's going to be much appetite to break their trust; MSFT is more likely to cut funding before completion which would create some chaos than the steering committee is to violate an agreement around funding (MSFT has made specific long term commitments they're going to keep, but those commitments are only for a few years IIRC). [1] https://developer.vonage.com/en/blog/removing-pythons-gil-its-happening https://developer.vonage.com/en/blog/removing-pythons-gil-it...
        Sakos 2y ago
        Why is MSFT so interested in funding this?
        robertlagrant 2y ago
        MSFT are keen to invest in popular development tools such as Python, Javascript, and Git. They hired Guido; they bought NPM; they bought GitHub. I don't know what the plan is, but they haven't succeeded (outside of the corporate world, really, for C# and the functional world in F#) in making modern tooling and languages people want to use.
        skeledrew 2y ago
        If you have too steep a hill making inroads into a desired community, and there's enough money, just buy the thing that brings said community together.
- logicchains 2y ago
  The GIL causes a huge performance hit in data processing/ML by forcing the use of multi-process, which leads to a bunch of unnecessary copying of memory between processes unless you put in a bunch of effort to explicitly share memory. So in some cases the savings will be gigantic, from no longer unnecessarily copying huge dataframes between processes.
  - antupis 2y ago
    But usually, in spaces where you need speed Python is just an orchestrator or glue between pipelines, and actually, calculations are done by db or some c/c++/fortran library.
    - logicchains 2y ago
      Yes pandas/numpy calls C++ to do calculations efficiently, but the "glue" can still introduce significant slowdown relative to that when it's copying tens of gigabytes of dataframe unnecessarily between processes. Of course that slow part itself could also be moved to C++, but that's much more effort then just parallel mapping over the dataset in Python with no copying/multiprocessing, as will be possible with no-gil.
      - aragilar 2y ago
        Bad code/quick hacks will always be slow (but can be great for prototypes), and sometimes it's worth planning how you're going to process something rather than piling on multiprocessing. Once you reach the point of multigigabyte IPC, it's worth spending the time doing it right.
        robertlagrant 2y ago
        Building libraries on a GIL-less Python would enable people to access that power without them all building it from scratch themselves.
        2y ago
hyperbrainer 2y ago
I would use python much more if every version did not have these many breaking changes, especially with the removal of the GIL. Shame they did not learn from 2 to 3.

We already know the upper bound of perf improvement – existing perf * number of cores. It will be worse than that though, as all the GILectomy plans make single-threaded performance worse. So if you're expecting something better than that, you will be disappointed.

vlovich123 2y ago
All the GILectomy plans IIRC also include single threaded performance improvements to offset any such costs. So while performance vs GIL is maybe worse for single threaded for the same Python version, performance will still be ahead of where it is today for single-threaded python (assuming everything goes according to plan). That's also why multi-threaded performance will be more than just existing perf * number of cores (vs what it is today, not what removing the GIL alone provides).
- eviks 2y ago
  But it doesn't offset anything since you get all the other improvements anyway, they're not tied to gil/nogil
  - vlovich123 2y ago
    I could be misremembering, but I thought that the MSFT team proposed those performance improvements specifically to offset any concerns about single threaded performance degradation from removing the GIL. Thus even if development is happening in parallel by independent (which I thought it wasn't - I thought it was all 1 team doing this work), it was predicated upon nogil being accepted in the first place. Thus if GIL were to remain in Python, then this performance work wouldn't be happening.
    - eviks 2y ago
      Maybe the work wouldn't be happening without the noGIL work, but once it's happened it's not tied to the GIL, you can pick those improvements and continue with a GIL-only Python
      - vlovich123 2y ago
        This post is literally about step 1: add this behind an unsupported experimental flag to get more insights. Step 2 is mid-term to make it a supported option based on readiness (within another 2 years). Step 3 is making it the default & then removing the GIL [1]. Steps 2 and 3 may not happen if some major unsolvable obstacle appears. But I doubt it's going to be so easy to reverse this direction. Given MSFT is driving all of this right now, it's hard to imagine there's going to be much appetite to break their trust; MSFT is more likely to cut funding before completion which would create some chaos than the steering committee is to violate an agreement around funding (MSFT has made specific long term commitments they're going to keep, but those commitments are only for a few years IIRC). [1] https://developer.vonage.com/en/blog/removing-pythons-gil-its-happening https://developer.vonage.com/en/blog/removing-pythons-gil-it...
        Sakos 2y ago
        Why is MSFT so interested in funding this?
        robertlagrant 2y ago
        MSFT are keen to invest in popular development tools such as Python, Javascript, and Git. They hired Guido; they bought NPM; they bought GitHub. I don't know what the plan is, but they haven't succeeded (outside of the corporate world, really, for C# and the functional world in F#) in making modern tooling and languages people want to use.
        skeledrew 2y ago
        If you have too steep a hill making inroads into a desired community, and there's enough money, just buy the thing that brings said community together.
logicchains 2y ago
The GIL causes a huge performance hit in data processing/ML by forcing the use of multi-process, which leads to a bunch of unnecessary copying of memory between processes unless you put in a bunch of effort to explicitly share memory. So in some cases the savings will be gigantic, from no longer unnecessarily copying huge dataframes between processes.
- antupis 2y ago
  But usually, in spaces where you need speed Python is just an orchestrator or glue between pipelines, and actually, calculations are done by db or some c/c++/fortran library.
  - logicchains 2y ago
    Yes pandas/numpy calls C++ to do calculations efficiently, but the "glue" can still introduce significant slowdown relative to that when it's copying tens of gigabytes of dataframe unnecessarily between processes. Of course that slow part itself could also be moved to C++, but that's much more effort then just parallel mapping over the dataset in Python with no copying/multiprocessing, as will be possible with no-gil.
    - aragilar 2y ago
      Bad code/quick hacks will always be slow (but can be great for prototypes), and sometimes it's worth planning how you're going to process something rather than piling on multiprocessing. Once you reach the point of multigigabyte IPC, it's worth spending the time doing it right.
      - robertlagrant 2y ago
        Building libraries on a GIL-less Python would enable people to access that power without them all building it from scratch themselves.
        2y ago

hyperbrainer 2y ago

I would use python much more if every version did not have these many breaking changes, especially with the removal of the GIL. Shame they did not learn from 2 to 3.