A Steering Council notice about PEP 703 (Making the Global Interpreter Lock Optional in CPython)
discuss.python.org
Posting for the whole Steering Council, on the subject of @colesbury’s PEP 703 (Making the Global Interpreter Lock Optional in CPython). Thank you, everyone, for responding to the poll on the no-GIL proposal. It’s clear that the overall sentiment is positive, both for the general idea and for PEP 703 specifically. The Steering Council is also largely positive on both. We intend to accept PEP 703, although we’re still working on the acceptance details. As we’ve done a few times in the past, we ...

It’s clear that the overall sentiment is positive, both for the general idea and for PEP 703 specifically. The Steering Council is also largely positive on both. We intend to accept PEP 703, although we’re still working on the acceptance details.

Long-term (probably 5+ years), the no-GIL build should be the only build. We do not want to create a permanent split between with-GIL and no-GIL builds (and extension modules).

Short term, we add the no-GIL build as an experimental build mode, presumably in 3.13 (if it slips to 3.14, that is not a problem

  • pnutzh4x0r@lemmy.ndlug.orgOPEnglish
    13·
    1 year ago

    Pretty exciting… I just hope they are able to effectively avoid another long transition ala python2 -> python3.

    • UlrikHD@programming.dev
      5·
      1 year ago

      Guido once said on a podcast that if they ever ended up doing python4, removing the GIL might be one of the reason for that move. He wanted to avoid the issues we got with python2 - > 3 though. I wouldn’t worry too much.

    • pnutzh4x0r@lemmy.ndlug.orgOPEnglish
      12·
      1 year ago

      It will depend on the nature of how the threaded code is structured (how much is sequential, how much is paralle, Amdahl’s law, etc), but it should at least be more effective at scaling up and taking advantage of multiple cores.

      That said, the change would come at a cost to single threaded code. From the PEP 703:

      The changes proposed in the PEP will increase execution overhead for --disable-gil builds compared to Python builds with the GIL. In other words, it will have slower single-threaded performance. There are some possible optimizations to reduce execution overhead, especially for --disable-gil builds that only use a single thread. These may be worthwhile if a longer term goal is to have a single build mode, but the choice of optimizations and their trade-offs remain an open issue.

      • Rev@ihax0r.comEnglish
        2·
        1 year ago

        imho its a cost we should pay. CPU’s are getting more cores not faster ones.