13 ms·

Intent to approve PEP 703: making the GIL optional

478 points by pablogsal 3y ago

sheepscreek 3y ago
I do most of my performance coding in Numba which comes with a nogil mode. Still, I have been looking forward to this. The fewer layers we can have in our libraries, the better!
m3kw9 3y ago
What does this mean?
- hgs3 3y ago
  Python uses a GIL (global interpreter lock) which prevents both Python code and native C modules from executing in parallel in the interpreter. Removing the GIL means Python could provide in-process parallelism.
deleted 3y ago
[deleted]
mlryyc 3y ago
[flagged]
- dragonwriter 3y ago
  Approving a PEP isn’t just flipping a bit, there are other decisions which come with it; this is process transparency and, implicitly, calling for feedback relevant to those other bits.
- mkl95 3y ago
  Considering Python is probably the most popular language ever, I would say the members of the council keep a pretty low profile. There are declining languages with userbases orders of magnitude smaller that make the front page more often.
willm 3y ago
I'm looking forward to a GIL-less Python. I think the SC's pragmatic approach is the right one.
- deleted 3y ago
  [deleted]
frfl 3y ago
If I remember Guido van Rossum did mention the status of the GIL in one of the Lex Friedman episodes [1] he was on (it's been a while, so I may be misremembering). Surprised to see a big decision like this happen so quickly. Did Meta's announcement play a big role in this [2]? [1]: https://www.youtube.com/watch?v=-DVyjdw4t9I https://www.youtube.com/watch?v=-DVyjdw4t9I [2]: https://news.ycombinator.com/item?id=36643670 https://news.ycombinator.com/item?id=36643670
- KRAKRISMOTT 3y ago
  Removing him as BDFL was probably the best thing to have happened to Python. He never prioritized performance as a top priority, at least not the same way Lua, JavaScript and Java did. Even Ruby has a JIT now.
  - ambivalence 3y ago
    You know that people change their minds and now Guido is working as part of a team at Microsoft that is literally called "Faster CPython"?
  - v3ss0n 3y ago
    Python had JIT for long, it's called PyPy, One of the most ambitious project ever happened to opensource
  - yjftsjthsd-h 3y ago
    > Removing him as BDFL was probably the best thing to have happened to Python. He never prioritized performance as a top priority That doesn't follow; you're assuming that Python should prioritize performance as a top priority, which is very much not a given. Python has always excelled at being easy to use, being flexible, being a great glue language - but performant? An interpreted, dynamically typed language? That's like making a C interpreter - you can do it, but that doesn't make it a good idea.
    - KRAKRISMOTT 3y ago
      > An interpreted, dynamically typed language? That's like making a C interpreter - you can do it, but that doesn't make it a good idea. And yet despite your complaints, JavaScript, Lua and Julia continue to rise in popularity.
tremon 3y ago
I know they say specifically that they don't want a repeat of the Python3 transition scenario, but the approach they're taking now still veers eerily close to that path, at least it looks that way to me. A lot will depend on the Python community and the distribution channels. I could see the community struggling to adopt it in a timely fashion, or distributions jumping the gun (Ubuntu, Fedora, Anaconda). Maybe it's too early to make hard decisions, but how much control does the SC really have to avoid such a scenario?
- trwsxcn 3y ago
  Yes, it will resemble the 2to3 scenario. Corporations that pledge support will mechanically convert some projects (pestering the actual developers or threaten with forks?), bugs will be ironed out by the actual, unpaid developers over years. But apparently Python needs some "success" and this makes a good bullet point. Correctness does not really matter in the Python world.
  - miraculixx 3y ago
    Is it success though?
- a_nop 3y ago
  They kind of burned a breaking major version transition for no good reason with 2-to-3, now they are prefacing a major change with "it won't be like 2-to-3". It sounds like they may be maintaining two operating modes in CPython 3 instead of going forward with another major transition, just because of that history.
  - jborean93 3y ago
    > They kind of burned a breaking major version transition for no good reason with 2-to-3 The unicode/text changes alone were a pretty good reason. Division producing floats are also a nice change IMO. I don’t want to discount the challenges with the transition but saying there was no good reason isn’t right to me.
mappu 3y ago
With PEP703 you would compile Python either for multi or single-threading mode. The mode affects the ABI and therefore which C extensions are available. Eventually all C extensions would have an available port to the new ABI. The chosen solution is similar to how PHP used TSRMLS_ macros in the Zend engine - if threadsafety (ZTS) was #defined, all functions took an extra thread context parameter, breaking ABI.
- miraculixx 3y ago
  How did it work out for PHP?
  - no_wizard 3y ago
    Honestly it didn't. PHP didn't get threads. It did eventually get Fibers though, which I suppose may have been in part influenced by this work
  - mappu 3y ago
    The main benefit of the threadsafe builds was reentrancy support for multithreaded web servers (e.g. IIS / some apache MPMs). They were only slightly slower for single-threaded code. The new PHP 8 fibers are only coroutines on a single thread, but PHP has had fork/join since 2001 (!), which works pretty well with Linux CoW. There has been a pthreads extension since about 2012. However keeping a 1:1 pthreads API prevents some optimization possibilities [1], so the new hotness is php-parallel [2], which will transparently copy closed-over variables to a subinterpreter. 1. https://github.com/krakjoe/pthreads/issues/929#issue-410636734 https://github.com/krakjoe/pthreads/issues/929#issue-4106367... 2. https://www.php.net/manual/en/philosophy.parallel.php https://www.php.net/manual/en/philosophy.parallel.php
- samus 3y ago
  All C extensions are available when running without GIL. A challenge for distribution is that all extensions will have to built twice to be compatible with the two Python builds. However, few source code changes are required where the developers don't want to make it compatible with running without GIL. Executing such extensions forces using the GIL for the whole interpreter, which is slower than the GIL-only build.
miraculixx 3y ago
Unpopular opinion: This is a missed opportunity. What? Python could have been the one language with a sane multithreading model. Now it risks becoming a second version of Java. I fear this will make it a less attractive programming language, not least because it might lose its beginner friendlyness. For example, without the GIL a lot more care must be put into designing your programs. This can be true even though your own code is single threaded, for example when you use a library that is multithreaded and has callbacks to your code Why? Free threading as introduced by PEP 703 is well known to be errorprone, hard to get right and generally advised against, unless you know exactly what you are doing. In other words free threading is for expert (as in very experienced) use only. And Python already has an expert mode - called Cython oer Numba to name just two. Personally I can see no good will come from bringing free threading to the masses. Yes it addresses a common critique (by many) and need (by very few), but it addresses it in a very risky way (for the vast majority of Python users). A better alternative IMHO the far better and still my preferred approach would have been to favor a per-thread GIL with an explicit mode to share particular objects. This would benefit everyone without the risks. It would be consistenly beginner friendly, and above all, offer a safe path to concurrent programming without impacting the whole ecosystem. Heck we could even call it the "Pythonic Threading Model", and it would be seen as a differentiator.
- ajkjk 3y ago
  Why convince you otherwise? You're the one with the weird opinion, you should be convincing us.
  - n2d4 3y ago
    Heads-up, the parent edited their comment to remove that sentence and added some "convincing" instead, so that's why your comment looks out of place.
    - ajkjk 3y ago
      oh, lol. thanks. guess they agreed with me!
- 3y ago
mepian 3y ago
I wonder if there will ever be Python 4, it seems that the core developers want to avoid bumping the major version number ever again after 3 under any circumstances.
- miraculixx 3y ago
  Yes bc they fear a Py3 to 4 transition would be perceived as a major burden. I'm afraid we'll soon learn its not the version # that's burdensome, but the real or perceived(!) incompatibility between versions. I wonder if introducing such a monumental change in a build flag of the minor version is really wise. Certainly its not in line with any interpretation of semantic versioning (to be fair I think the PSF does not claim to use that).
Alifatisk 3y ago
No-GIL means better performance at the cost of being less beginner-friendly, right?
- Waterluvian 3y ago
  Not really. The GIL doesn’t actually make threading easier for a typical developer as they still have to worry about thread safety. You can ignore locks if you know what Python operations are atomic. But that’s incredibly perilous and you really shouldn’t try given that relies on implementation details. Eg. What if you didn’t realize a setter was overridden and setting to a dict-like isn’t atomic anymore? It’ll make the Python source code much more complex and complicated, which is probably not a big deal, though I’ll say the CPython source is quite brilliant. It’ll also mean for C library developers that they can’t assume Python opcodes are atomic. But I’m not sure C library developers will really mind too much because they already worry about this kind of stuff.
- JamesSwift 3y ago
  I think multi-threadedness is already an intermediate level concept so maybe its not a big downside. In turn, the ones that understand and need the performance get it.
- tedivm 3y ago
  Only if the user explicitly uses threads. By default people can still approach their code in the exact same way they do. I imagine most users won't think about threads at all, but may relay on frameworks and libraries that take advantage of them under the hood.
- qbasic_forever 3y ago
  It's only more performance if you're using the threading primitives and spawning new threads, moving work to them to do in parallel, etc.--this isn't something any beginner will consciously be doing. It might actually be slower in regular single process use that 99% of python users use (since the GIL is there for a very good reason and synchronizing access to python's internal state doesn't just happen for free or without some cost somewhere).
Waterluvian 3y ago
I’m glad they’re very conscious about how easily this could turn into a Python 4 debacle. They’ll have to be intensely careful not to accidentally affect yes-GIL behaviour. All kinds of weird cases are possible if any sort of emulated GIL isn’t exactly like with a GIL.
- miraculixx 3y ago
  I am sure the intent is good. I am not so sure it is possible to avoid. They already say it could take 5+ years of having gil + nogil exist in parallel. For any tool builder that means their cost has just doubled for the next five years, at least. Why? Because people will want to use tools in either mode, no matter if it is deemed productive or experimental.
  - slt2021 3y ago
    essentially the adoption of No-GIL Python will depend on: 1. In which version No-GIL will become default option in CPython 2. When that CPython version will come standard in LTS Linux distro 3. When all earlier LTS distros will go out of support 4. When companies switch from outdated to target LTS version of distro currently quite a lot of companies use python3.6 only because it comes standard with the Ubuntu 14.04.6 which happens to be the oldest LTS version - and companies have habit of migrating from out-of-support LTS version to currently-supported-oldest-LTS
    - pmontra 3y ago
      A customer on 18.04 just told me to wait another year and migrate their servers to 24.04 so they can stay there until 2029, or will that be 2030? They are on the standard 5 years LTS support, not the extended 10 years one.
- travisjungroth 3y ago
  I’ve seen no description of how this won’t be like 2 -> 3 except: 1. We don’t want it to be. 2. We’ll give up quickly if it is. Those are both important points. But there seems to be an important missing third piece of “and we’ll achieve this by…”.
vasili111 3y ago
What are advantages of non-GIL Python?
- KMnO4 3y ago
  GIL is a promise from the internal implementation (eg CPython) of Python that things will happen atomically within the Python interpreter. This means that when multiple threads try to access and modify Python objects at the same time, the GIL ensures that only one thread can execute Python bytecode at any given moment, preventing potential conflicts and ensuring data integrity. However, this comes at the cost of limiting the full utilization of multiple CPU cores for certain CPU-bound tasks. Non-GIL adds some complexity to the implementation and some risk when writing multithreaded code at the benefit of improving performance.
  - fbdab103 3y ago
    At the current implementation, GILless is a performance regression[0], of 5-7% [0] https://peps.python.org/pep-0703/#performance https://peps.python.org/pep-0703/#performance
  - slt2021 3y ago
    But people are not doing cpu bound tasks in native python (performance is a joke), it all comes down to calling a C library that is optimized for compute - what will be the change that GIL brings here?
    - AlphaSite 3y ago
      There is a JIT being built for Python, so performance is being attacked from 2 avenues, single threaded and multithreaded.
- lostdog 3y ago
  In GIL Python, you might think you could speed something up by multithreading, but it turns out you can't. The GIL will just run it serially anyways. No-GIL means it is possible to run things in parallel (without resorting to fancy C extensions).
valyagolev 3y ago
there's a lot of code I wrote (and saw people write) in Python over the years, conscious that noone will ever run it in threads (ofc it's possible, but typically pointless), thus going quite easy on things that wouldn't be thread-safe. this used to quite a comfortable stance. community ended up inventing other ways to share state, other ways to vectorize, other ways to avoid blocking on I/O, that might sometimes be annoying, but evolved to be quite reasonable for Python. giving up this stance? a lot of code is instantly a legacy, and a lot of it is a legacy people won't even know about before they notice the problems. and for what? i must say that i have no experience running Python without GIL so my idea of the ways things can be not thread-safe is purely speculative/borrowed from very different languages (that I finally moved on to long ago, thank god). so maybe i'm wrong, i misunderstand the impact, and all this code is just fine
- miraculixx 3y ago
  Well said. Thanks
- valyagolev 3y ago
  people in this thread mention that, for some reason, "even with GIL you still have to write thread-safe code", which is an admirable stance, but I don't think many people do it, because their webserver or whatever uses the many single-threaded processes model and they don't want to waste time on that
  - miraculixx 3y ago
    Indeed. And the reason they use multiprocessing is bc they have learned that Python's multithreading is not a good option in cpu bound tasks. The blessing in disguise of course being that multiprocessing is also a shared nothing model, so (mostly) lock free programming is the default. Oth if you have a need for concurrently accessed shared memory/resources and need locks, it comes with an explicit cost. I think that's a good thing. In the future the default concurrency model will be shared everything free threading, and all hell might break loose. Hopefully not.
    - 3y ago
ggm 3y ago
Lots of C library code for decades carried man page warnings it was unstable for use in async, re-entrant and recursive contexts. We learned how to cope and incrementally re-entrant safe versions deployed without too much API instability. Maybe time has healed wounds and caused me memory loss of the pain of discovery you'd tripped over them. String parsing which tokenised in-place. DNS calls which used static buffers. Things which exploited Vax specific stack behaviour. I think the GIL has been a blessing and a curse.
- pwdisswordfishc 3y ago
  What is Vax specific stack behaviour?
- neilv 3y ago
  I remember scouring those C runtime docs, for every non-reentrant function. It might be what got me in the habit of checking docs when using some API that I know moderately well, just in case there's some important detail I missed before, or something had changed. Around that time, doing cross-platform C++, I got an early look at Java, with concurrency built in from the start, along with GC and various other nice features that were easier to use than C++, and I "knew" it was going to be huge. (But who knew that the MIS people would take over Java, when it seemed clearly targeted at non-MIS programmers, and now MIS people are stuck with the C++ syntax and verbosity, after coming from 4GLs, etc.) Then mainstream programmers picked up Python, which, IIRC, originally was an embeddable extension language, which was why it was simple. And for which the GIL made more sense.
  - eru 3y ago
    > I got an early look at Java, with concurrency built in from the start, [...] and I "knew" it was going to be huge. And Java doesn't even have good (conceptual) support for concurrency. Compared with eg Erlang, Rust or even Haskell. But Java was still better at it than C or C++ at the time.
    - dboreham 3y ago
Systemmanic 3y ago
GIL: Global Interpreter Lock. Good explanation here: https://realpython.com/python-gil/ https://realpython.com/python-gil/
jmount 3y ago
Why would you even want a no-GIL Python? Java and C showed how much more effort it takes to maintain slower thread safe code for no real benefit. Parallelize at the fork level or at the isolated numeric library level.
- qbasic_forever 3y ago
  Yep I think over the next year a lot of python devs are going to learn threading isn't magic pixie dust that makes your code fast, and in reality is starts by making your code very unstable.
  - miraculixx 3y ago
    I'm afraid that's exactly what will happen. Unfortunately the overarching sentiment will not be "multithreading is hard" but "Python has become really hard to work with"
- commonlisp94 3y ago
  Exactly. I think a lot of the negativity about GIL comes from a misunderstanding about forking processes. If python is being used as a scripting language, and spawning other tools, you're already getting free multi-core. A similar misunderstanding exists about SQLite and concurrency.. but that's a topic for another time.
  - AlphaSite 3y ago
    Forking had a ton of its own downsides, it’s not a free lunch either, from poor ergonomics to communications overhead it works well for somethings and very poorly for others.
    - miraculixx 3y ago
      Yes, the same is true for free threading. Yet people assume free threading is free concurrency and that's the problem.
andrewstuart 3y ago
As a Python developer, what would be the benefit of no GIL?
- deleted 3y ago
  [deleted]
- qbasic_forever 3y ago
  Slightly faster performance when you write multithreading code correctly (much easier said than done). Very few python devs are actually running into this as a bottleneck day to day.
slt2021 3y ago
Naiive question: Who needs No-GIL when we have asyncio and multiprocessing packages ? never ever had a problem with GIL in python, always found a workaround just by spinning up ThreadPool or ProcessPool, and used async libraries when needed. is there any use case of No-GIL which is not solved by multiprocessing ? I thought Single threaded execution without overhead for concurrency primitives is the best way to high performance computing (as demonstrated by LMAX Disruptor)
- miraculixx 3y ago
  Some of the use cases advocating for nogil come from the AI/ML group of library builders, stating a need for free threading concurrency.
  - pama 3y ago
    Agreed. Feeding the GPUs with multiple forked memory-hogging processes is no fun and leads to annoying hacks. And, yes, as per your other post, there could have been other solutions to this problem, some of which might have been better.
    - miraculixx 3y ago
      Yes but that's a very particular use case that could have been well served with a per gil thread and arena based memory for explicitely shared objects.
- dragonwriter 3y ago
  > is there any use case of No-GIL which is not solved by multiprocessing ? Anything that benefits from both parallelism and replacing IPC overhead with shared data between parallel tasks.
  - slt2021 3y ago
    but it would incur overhead of concurrency control: mutex, locks, semaphores. I dont believe python will ever have atomic operations, even if it had - they still incur significant overhead for concurrency control. sharing state between threads is such a narow niche use case, this pattern is practically solved by memcached/redis for larger scale python based systems
nnx 3y ago
I hope this won't make Python's dependency hell even worse, but I'm not hopeful.
- phkahler 3y ago
  It's optional. Just keep using the GIL.
- qbasic_forever 3y ago
  Yeah it's going to be weird for some years where some libraries support no-GIL and others don't, while folks cry about the ones that don't support it holding them back. Like asyncio's introduction we'll probably see core stuff like http requests, file IO etc. all now have an entirely new permutation of libraries made to support non-GIL mode. This is going to get pretty spicy as stuff like http already has regular (blocking IO) and asyncio (non blocking IO) versions, so now do they need regular non-GIL and asyncio non-GIL versions too? Is the default for a library author going forward to be creating four permutations of your library with vastly different behavior in each of them? Yuck.
  - miraculixx 3y ago
    import this ;)
  - ies7 3y ago
    > while folks cry about the ones that don't support it holding them back. And someone may prefer to make NON GIL wall of shame/fame instead of directly contributing to those libraries
nicechianti 3y ago
[dead]
bjourne 3y ago
This can (and I think will) cause issues for C extensions because many are written without multi-threading in mind. Here is a small example which is unsafe if lst can be accessed from another thread: https://news.ycombinator.com/item?id=36649769 https://news.ycombinator.com/item?id=36649769 Note that the code may cause a context switch even today if the C code callbacks into Python bytecode (via a __del__ method) and the bytecode is long enough (100 instructions I think). However, that is extremely unlikely and much C extension code is not written with such situations in mind. People using C extensions may also rely on them executing atomically. For example, you could have a thread pool that posts and receives from a numpy array. Would work fine today but break without the GIL.
- qbasic_forever 3y ago
  Yep there are a ton of issues like that to be found, and unfortunately they will manifest as difficult to find and debug race conditions. This is why the proposal and work is to make non-GIL mode entirely optional and not the default. It just means for the brave few that flip it on and use it, be prepared to spend a huge amount of time finding and fixing subtle race conditions in decades of old python library code. The early adopters are going to be in for a lot of pain, or more likely they'll restrict their use of non-GIL processes to very specialized and dedicated processes that have as few dependencies as possible.
  - miraculixx 3y ago
    The intent is to make no GIL the default eventually.
    - n2d4 3y ago
      I don't think this is true. There are fairly strong voices on both sides inside the community, at this time it's pretty uncertain. To quote Guido: >Let’s not blow it this time. If we’re going forward with nogil (and I’m not saying we are, but I can’t exclude it), let’s make sure there is a way to be able to import extensions requiring the GIL in a nogil interpreter without any additional shenanigans https://discuss.python.org/t/pep-703-making-the-global-interpreter-lock-optional-3-12-updates/26503/19 https://discuss.python.org/t/pep-703-making-the-global-inter...
amluto 3y ago
I’m not in love with some of the details. PYTHONGIL is an awkward tri-state. 0, 1, and unset all do different things. Wouldn’t some self-explanatory strings be better? PYTHONGIL=auto for the default, force-gil and force-nogil for the forced modes.
catnibbler 3y ago
Is it really too late to not do this ? The only reason to get rid of the GIL is to help threading, but that's not a thing we should be doing. Threads need to just die, and be replaced by something less idiotic. Seriously, having the CPU run fragments of your program at random, so that all the previously ordered pieces are now contending with each other and even themselves ? How can anyone not see that this is the stupidest idea in the world ?
- Jabrov 3y ago
  As opposed to?
  - n2d4 3y ago
    In Python, asyncio and multiprocessing packages can get nearly the same or better performance for IO- and CPU-intensive tasks respectively as no-GIL multithreading (and are more performant than GIL multithreading), with only a tiny fraction of the pitfalls. For any use case where the last few percent matter, consider not using Python (which will be much much more significant). Regardless, we did somehow end up here, and there's plenty of multi-threaded Python code that would benefit from no-GIL, so I support the proposal just from a practical perspective. But when designing a new codebase, you'll almost almost almost always want to avoid Python threads, even with no-GIL.
    - usrbinbash 3y ago
      > asyncio ...is useless for CPU bound tasks. The event loop uses only one core. > multiprocessing ...relies on IPC and running actual system processes, both of which have alot more overhead than switching thread context and using shared memory. > For any use case where the last few percent matter, consider not using Python (which will be much much more significant). Here is an interesting question: If asyncio and multiprocessing already give us "nearly the same or better performance", then why is "use another language" such a common advice to escape parallelism-problems in Python? Because, curiously enough, the languages that are usually recommended for this (C, Go, Rust, C++, Java) all implement thread-based parallelism.
kalb_almas 3y ago
Even with improved support for parallelism, what role will Python have in the future if Mojo makes good on even half of its promises?
- nologic01 3y ago
  Mojo is not Python. The underlying pressure on the Python ecosystem is to transition to a post-Moore's law era and effectively become a HPC platform where the "same" code runs on a CPU, a GPU, multicore, clusters etc. Python may feel the pressure more than others because of the GIL and the fact it is used in compute intensive tasks more than others. But this major need to transition to easy and seamless HPC/heterogeneous computing is the same for all languages. The question is who will get there first.
  - Too 3y ago
    Mojo is a superset of python, with goal to be able to run any python code and to import any python module under its own execution model, that runs magnitudes faster. Now, if that actually works as advertised, it would render python obsolete and become mojo instead, even if the authors don’t put it that way. Lex Fridmans podcast had an interview with one of the creators recently. Chris Lattner, who is also the creator of LLVM and Swift. Recommended listen for those who haven’t heard of mojo yet, if you have 3h to spare.
TX81Z 3y ago
But how will I waste thousands of person hours battling subprocesses now????
carabiner 3y ago
We are so back.
ahgamut 3y ago
"Python 4, but not really", because we want to squeeze out more multithreading performance and be cool again. Some questions from reading the OP: - How much does performance improve due to this No-GIL thing? Is it greater than 2x? For what workloads? - Do I have to compile two versions of every extension (gil/nogil)? I would prefer building extensions does not get any more complicated. - Can I automatically update my code to handle nogil? (a tool like lib2to3 or six)
- donio 3y ago
  The estimate in the PEP is that it will be 5-8% slower. Having to use more granular locks and atomic operations has a cost. https://peps.python.org/pep-0703/#performance https://peps.python.org/pep-0703/#performance
ram_rar 3y ago
This seems somewhat delayed, and it may be considered too little, too late. Python community had the chance to leapfrog and embrace alternative concurrency abstractions, such as go routines etc, but it appears that this opportunity was not fully utilized. After enduring the arduous process of migrating from Python 2 -> 3 and navigating the complex world of dependencies, my hope is that we won't encounter another nightmare of dependency management, forcing users to choose between GIL and no-GIL builds.
- tgv 3y ago
  Something akin to go routines won't solve the C-library problem.
raminf 3y ago
Remember the transition of text to Unicode? 32 to 64-bit? Intel to ARM? Y2K? No-GIL is a much smaller shift. It can follow the same transition path without radically breaking things. And if some things do break, there would be a well-defined way to handle those cases. We all somehow survived those. Glad to see forward motion on this. It will open up a lot more terrain that has been marked off as untenable. One of the things about early Swift that they got right was building breaking changes into the promise. Everyone knew where they stood and adjusted just fine. Sometimes I wish Python would take the same path.
- viraptor 3y ago
  I think that's a bit different. 32 to 64 - you could test whether it works. Same for arm. Same for y2k. Sure, maybe the testing wouldn't cover the failing case, but the testing you did would be deterministic. But here? Test all you want and the answer is: it's either correct or you haven't triggered the right race yet.
  - samus 3y ago
    Yes, it is different because nobody would be forced to run the interpreter without the GIL. Applications where race conditions are unacceptable can keep using the GIL build. Even the `--disable-gil` build can be forced to keep using the GIL.
- geewee 3y ago
  I mean going from text to unicode did pose a huge problem for python specifically.
  - asah 3y ago
    I have PTSD from that transition.
- School-Cotton 3y ago
  I’m not worried about the difficulty of migration; I’m worried that the end state might actually be worse than what we have now.
pyeri 3y ago
Let us wait and watch but I somehow feel that this no-GIL mode is just a band-aid solution to Python's performance problem. The cause goes deep inside the core of Python, it gradually came to this stage as more and more features got added to the language since the 3.x transition. I think new language features shouldn't just be added to provide syntactic sugars or coding shortcuts to programmers or just because a certain feature has become very cool (like lambda functions, for eg). I'm glad that the Python community has realized that performance is an issue and started working on things like no-GIL mode. People often say that Python's biggest strength is its readability and easy syntax but I disagree. Python's real strength is the enormous third party library ecosystem, popular packages like numpy, pandas, scikit, etc. which have almost become addictive in most data science projects. But now, people are thinking of other alternatives to these due to Python's performance issues. Other ecosystems like golang and rust are getting built at rapid pace and at some point, they will also have (more performant) equivalents of these packages if public shows enough interest.
- ehsankia 3y ago
  Hasn't python been getting much faster since 3.x? Where is your evidence that new py3 features is making python slower?
MrYellowP 3y ago
I'm going to miss the thread-safety non-GIL python offered. That being said, this is interesting. Can we get an in-python fork() mechanic ... please?
- pritambaral 3y ago
  > I'm going to miss the thread-safety non-GIL python offered. The old method — which is the GIL, or non-non-GIL — provides no thread safety to Python code. It only protects C code > Can we get an in-python fork() mechanic ... please? You probably want Multiple Subinterpreters: https://github.com/python/cpython/issues/84692 https://github.com/python/cpython/issues/84692
deleted 3y ago
[deleted]
dwaite 3y ago
I sure hope they decide to call execution of mixed GIL and no-GIL codebases "amphibious mode"
worik 3y ago
I am not a python programmer. What is the use case for this? Who needs it?
- 12_throw_away 3y ago
  > I am not a python programmer I _am_ a python programmer. > What is the use case for this? > Who needs it? This can be answered with a simple user story: As "THE PYTHON STEERING COUNCIL", I want to "GET RID OF THE GIL", so that "PEOPLE WILL STOP WHINGING ABOUT THE GIL." To be fair, there's another group of people who stand to benefit. Namely, any python programmers who currently believe that "threads are an easy way to make my program go faster" will soon be the recipients of a valuable learning experience.
  - miraculixx 3y ago
    Nice! ;)
kgeist 3y ago
Is the following possible? - library author marks their library "no-GIL" after making sure it's thread-safe without GIL - if the interpreter sees this metainformation, it temporarily disables GIL for the current OS thread while running the library's code - result: old versions of Python can still run no-GIL libraries under GIL, while new versions of Python allow to gradually remove GIL Or it's not how CPython works?
- BGINBarbarian 3y ago
  Afaik, nogil will be a compile flag, which means that when there are two builds, you separately compile Gil and nogil builds. They will be two separate programs/binaries/packages. It could be possible for something like conda to install both binaries, then run your program with the one that matches the library flags, but python itself could not do this (afaik).
dotnet00 3y ago
I'm looking forward to this, Python plays a fairly significant role in our scientific computing code and not having to have entirely separate processes will be very convenient for cutting down data duplication.
akdor1154 3y ago
Get exc's happening!ited, it
lraxny 3y ago
The ruling class in python-dev are populists who are not threading experts. Python is run by the wrong people. They will approve something if it serves a corporation. The submission here is likely CYA, so they can say that "they asked the community". There is no appreciation for people doing grassroots open source software. If Instagram can add another hack instead of switching to Java, it will be approved. It is important to remember that paid corporate developers will have job security every time new pain is introduced in the Python ecosystem.
- miraculixx 3y ago
  I have the same impression though I think its not intentional or otherwise ill intended.
hanselot 3y ago
for self in selfs:
JonChesterfield 3y ago
Exciting. Python is mostly written as C shared libraries that knew they had a global lock to rely on. Some of those do sufficiently simple things that they can run without any locking and all will be fine. Others will still need locking, but are now under pressure to run without the gil. Some of those are going to do DIY locking within their own bounds. Maybe what python has really been missing all these years is loads of ad hoc mutex calls scattered across the ecosystem. Data races and deadlocks introduced in the name of performance is not how I expected python to go out. edit: expanding on this pessimism a bit. Making C libraries written assuming a global lock thread safe is the sort of thing I'd expect concurrency experts to advise against and then make mistakes while implementing it. My working theory is that most people who wrote C extensions for python are not concurrency experts and are great programmers who won't back down from a challenge. The data-race/hang/segfault consequences of this combination look totally inevitable to me. Python application developers are not going to love the new experience and I'm thankful my products are not built on top of the python ecosystem.
- tgv 3y ago
  I think you're right. Making it an explicit opt-out, as is planned for the first stage, should be fine. Expecting to make it opt-in in 5 years seems too optimistic to me. It relies on all the library developers to fix their libraries (also the Python ones). That's tough work, and importantly, if done well, it will even go unappreciated: nobody will notice it. Many libraries have never had a multi-processing use case, others are so big that bugs are bound to happen, many of them subtle, so one guaranteed outcome will be unreproducible complaints and devs throwing in the towel. Opt-in will make people unhappy.
  - Arbortheus 3y ago
    Surely if it goes well people will see their existing python codebases become more performant with no development required aside from updating some dependencies? Not nobody will notice it. It seems like it could be a great outcome for developers.
    - 3y ago
elisbce 3y ago
Seems these guys never learn from the Python 2 -> 3 mess. GIL to NoGIL is even worse. Most changes from Python 2 to 3 are syntactic, but GIL to NoGIL could require a complete redesign and rewrite. Either it takes another 10+ years migrating OR nobody with a realistic production codebase with 10k dependencies can turn this No-GIL thing on.
ksec 3y ago
It will be interesting to see how this will be executed. I think many in Ruby land wanted something similar but couldn't get some general agreement. Ractors tried and arguably failed. We have Samuel Williams basically the one person pushing very hard for Async changes. Ruby could learn a lot once this is done, but at the moment GIL optional in python seems to be a 2030 goal.
birdyrooster 3y ago
Soon I’ll be able to ditch golang
- miraculixx 3y ago
  Right about ~2033
samsquire 3y ago
Thank you so much Python core developers and steering council. Python is one of my favourite languages along with Java and C. I greatly welcome true multithreading in Python. I use both multiprocessing and multithreading in Python for different projects. See [0] for my multiprocessing example and python Threads for IO heavy tasks in [1]. But it would be far more efficient to use true threads. Threads can communicate any amount of data in a single atomic almost instant operation. Using the local loopback interface or multiprocessing or pipes, this is not possible. I am working on a multithreading architecture I call three tier multithreading architecture https://github.com/samsquire/three-tier-multithreaded-architecture https://github.com/samsquire/three-tier-multithreaded-archit... My goal is extremely scalable and performant servers but Python is probably the wrong job for that. [0]: https://news.ycombinator.com/item?id=36897054 https://news.ycombinator.com/item?id=36897054 (my description of my use of multiprocessing) [1]: https://devops-pipeline.com/ https://devops-pipeline.com/ (my use of multithreading)
fulafel 3y ago
How will this impact single thread performance?
- miraculixx 3y ago
  From the POC implementation the reports state ~5-7% if memory serves right.
kerkeslager 3y ago
Two major problems here: 1. There are some improvements worth breaking reverse-compatibility for, and removing the GIL is such an improvement. Whether the changes in Python 3 were worth making breaking changes for is debatable: certainly I don't see "print" being a function as particularly valuable. But the flipside is that the 2-to-3 transition was overblown by a vocal minority. I've transitioned more than 5 codebases from 2 to 3, and in most cases, there were few problems. Most problems were with codebases where previous developers had pulled in libraries for everything, resulting in an amalgamation of abandoned libraries, but these codebases run into problems even without the core language breaking compatibility. The answer isn't to flame your language into never breaking compatibility, it's to not import all of pip and expect that to be a sustainable strategy. The situation we have now is that the steering committee has received so much heat from the vocal minority that they're terrified to make breaking changes. But removing the GIL should be a breaking change. It's too fundamental to how Python works to not be. So they're trying to remove the GIL and make it not a breaking change, which is a bad idea, because it is ultimately going to be a breaking change. It would be much better to admit this is a breaking change and start working on the transition plan, than to try the impossible task of making it not breaking because you're too terrified of your users to admit the truth. We've already seen this in Python 3.11 which broke code in my codebase. The changes to fix the breakage weren't hard, but I would have liked better communication that this might happen. But I also understand why this was hidden in a deprecation warning in a minor release rather than publicized, because the Python team is probably tired of being flamed for making breaking changes. 2. The more fundamental problem here is that a lot of other features of Python were built around the GIL. Most obviously, the async paradigms makes sense largely because of the GIL. Sans-GIL, it looks like in retrospect a send/recv actor model a la Erlang would have been a much better way forward. It's not really possible to reverse this, and this might be pushing Python toward a less cohesive set of features that don't really make sense together. This makes it feel like this is too little too late.
miraculixx 3y ago
The creator and lead maintainer of SQLAlchemy, one of the most popular and most used Python libraries for accessing databases (who doesn't?) gave a rather interesting response to PEP703. > Basically for the moment the GIL-less idea would likely be burdensome for us and the fact that it's only an "option" seems to strongly imply major compatibility issues that we would not prefer. (...) > Adding an entirely new mode of operation to cPython that's optional would be an enormous burden for us as far as ensuring we use APIs appropriately, adding support, testing, we would have to spin up new test workers to test SQLAlchemy in both modes of operation, we would be getting strange new race condition related issues reported https://github.com/sqlalchemy/sqlalchemy/discussions/10002#discussioncomment-6252988 https://github.com/sqlalchemy/sqlalchemy/discussions/10002#d...

478 points by pablogsal 3y ago

I do most of my performance coding in Numba which comes with a nogil mode. Still, I have been looking forward to this. The fewer layers we can have in our libraries, the better!

m3kw9 3y ago

What does this mean?

hgs3 3y ago
Python uses a GIL (global interpreter lock) which prevents both Python code and native C modules from executing in parallel in the interpreter. Removing the GIL means Python could provide in-process parallelism.

deleted 3y ago

[deleted]

mlryyc 3y ago

[flagged]

dragonwriter 3y ago
Approving a PEP isn’t just flipping a bit, there are other decisions which come with it; this is process transparency and, implicitly, calling for feedback relevant to those other bits.
mkl95 3y ago
Considering Python is probably the most popular language ever, I would say the members of the council keep a pretty low profile. There are declining languages with userbases orders of magnitude smaller that make the front page more often.

willm 3y ago

I'm looking forward to a GIL-less Python. I think the SC's pragmatic approach is the right one.

deleted 3y ago
[deleted]

frfl 3y ago

If I remember Guido van Rossum did mention the status of the GIL in one of the Lex Friedman episodes [1] he was on (it's been a while, so I may be misremembering). Surprised to see a big decision like this happen so quickly. Did Meta's announcement play a big role in this [2]? [1]: https://www.youtube.com/watch?v=-DVyjdw4t9I https://www.youtube.com/watch?v=-DVyjdw4t9I [2]: https://news.ycombinator.com/item?id=36643670 https://news.ycombinator.com/item?id=36643670

KRAKRISMOTT 3y ago
Removing him as BDFL was probably the best thing to have happened to Python. He never prioritized performance as a top priority, at least not the same way Lua, JavaScript and Java did. Even Ruby has a JIT now.
- ambivalence 3y ago
  You know that people change their minds and now Guido is working as part of a team at Microsoft that is literally called "Faster CPython"?
- v3ss0n 3y ago
  Python had JIT for long, it's called PyPy, One of the most ambitious project ever happened to opensource
- yjftsjthsd-h 3y ago
  > Removing him as BDFL was probably the best thing to have happened to Python. He never prioritized performance as a top priority That doesn't follow; you're assuming that Python should prioritize performance as a top priority, which is very much not a given. Python has always excelled at being easy to use, being flexible, being a great glue language - but performant? An interpreted, dynamically typed language? That's like making a C interpreter - you can do it, but that doesn't make it a good idea.
  - KRAKRISMOTT 3y ago
    > An interpreted, dynamically typed language? That's like making a C interpreter - you can do it, but that doesn't make it a good idea. And yet despite your complaints, JavaScript, Lua and Julia continue to rise in popularity.

tremon 3y ago

I know they say specifically that they don't want a repeat of the Python3 transition scenario, but the approach they're taking now still veers eerily close to that path, at least it looks that way to me. A lot will depend on the Python community and the distribution channels. I could see the community struggling to adopt it in a timely fashion, or distributions jumping the gun (Ubuntu, Fedora, Anaconda). Maybe it's too early to make hard decisions, but how much control does the SC really have to avoid such a scenario?

trwsxcn 3y ago
Yes, it will resemble the 2to3 scenario. Corporations that pledge support will mechanically convert some projects (pestering the actual developers or threaten with forks?), bugs will be ironed out by the actual, unpaid developers over years. But apparently Python needs some "success" and this makes a good bullet point. Correctness does not really matter in the Python world.
- miraculixx 3y ago
  Is it success though?
a_nop 3y ago
They kind of burned a breaking major version transition for no good reason with 2-to-3, now they are prefacing a major change with "it won't be like 2-to-3". It sounds like they may be maintaining two operating modes in CPython 3 instead of going forward with another major transition, just because of that history.
- jborean93 3y ago
  > They kind of burned a breaking major version transition for no good reason with 2-to-3 The unicode/text changes alone were a pretty good reason. Division producing floats are also a nice change IMO. I don’t want to discount the challenges with the transition but saying there was no good reason isn’t right to me.

mappu 3y ago

With PEP703 you would compile Python either for multi or single-threading mode. The mode affects the ABI and therefore which C extensions are available. Eventually all C extensions would have an available port to the new ABI. The chosen solution is similar to how PHP used TSRMLS_ macros in the Zend engine - if threadsafety (ZTS) was #defined, all functions took an extra thread context parameter, breaking ABI.

miraculixx 3y ago
How did it work out for PHP?
- no_wizard 3y ago
  Honestly it didn't. PHP didn't get threads. It did eventually get Fibers though, which I suppose may have been in part influenced by this work
- mappu 3y ago
  The main benefit of the threadsafe builds was reentrancy support for multithreaded web servers (e.g. IIS / some apache MPMs). They were only slightly slower for single-threaded code. The new PHP 8 fibers are only coroutines on a single thread, but PHP has had fork/join since 2001 (!), which works pretty well with Linux CoW. There has been a pthreads extension since about 2012. However keeping a 1:1 pthreads API prevents some optimization possibilities [1], so the new hotness is php-parallel [2], which will transparently copy closed-over variables to a subinterpreter. 1. https://github.com/krakjoe/pthreads/issues/929#issue-410636734 https://github.com/krakjoe/pthreads/issues/929#issue-4106367... 2. https://www.php.net/manual/en/philosophy.parallel.php https://www.php.net/manual/en/philosophy.parallel.php
samus 3y ago
All C extensions are available when running without GIL. A challenge for distribution is that all extensions will have to built twice to be compatible with the two Python builds. However, few source code changes are required where the developers don't want to make it compatible with running without GIL. Executing such extensions forces using the GIL for the whole interpreter, which is slower than the GIL-only build.

miraculixx 3y ago

Unpopular opinion: This is a missed opportunity. What? Python could have been the one language with a sane multithreading model. Now it risks becoming a second version of Java. I fear this will make it a less attractive programming language, not least because it might lose its beginner friendlyness. For example, without the GIL a lot more care must be put into designing your programs. This can be true even though your own code is single threaded, for example when you use a library that is multithreaded and has callbacks to your code Why? Free threading as introduced by PEP 703 is well known to be errorprone, hard to get right and generally advised against, unless you know exactly what you are doing. In other words free threading is for expert (as in very experienced) use only. And Python already has an expert mode - called Cython oer Numba to name just two. Personally I can see no good will come from bringing free threading to the masses. Yes it addresses a common critique (by many) and need (by very few), but it addresses it in a very risky way (for the vast majority of Python users). A better alternative IMHO the far better and still my preferred approach would have been to favor a per-thread GIL with an explicit mode to share particular objects. This would benefit everyone without the risks. It would be consistenly beginner friendly, and above all, offer a safe path to concurrent programming without impacting the whole ecosystem. Heck we could even call it the "Pythonic Threading Model", and it would be seen as a differentiator.

ajkjk 3y ago
Why convince you otherwise? You're the one with the weird opinion, you should be convincing us.
- n2d4 3y ago
  Heads-up, the parent edited their comment to remove that sentence and added some "convincing" instead, so that's why your comment looks out of place.
  - ajkjk 3y ago
    oh, lol. thanks. guess they agreed with me!
3y ago

mepian 3y ago

I wonder if there will ever be Python 4, it seems that the core developers want to avoid bumping the major version number ever again after 3 under any circumstances.

miraculixx 3y ago
Yes bc they fear a Py3 to 4 transition would be perceived as a major burden. I'm afraid we'll soon learn its not the version # that's burdensome, but the real or perceived(!) incompatibility between versions. I wonder if introducing such a monumental change in a build flag of the minor version is really wise. Certainly its not in line with any interpretation of semantic versioning (to be fair I think the PSF does not claim to use that).

Alifatisk 3y ago

No-GIL means better performance at the cost of being less beginner-friendly, right?

Waterluvian 3y ago
Not really. The GIL doesn’t actually make threading easier for a typical developer as they still have to worry about thread safety. You can ignore locks if you know what Python operations are atomic. But that’s incredibly perilous and you really shouldn’t try given that relies on implementation details. Eg. What if you didn’t realize a setter was overridden and setting to a dict-like isn’t atomic anymore? It’ll make the Python source code much more complex and complicated, which is probably not a big deal, though I’ll say the CPython source is quite brilliant. It’ll also mean for C library developers that they can’t assume Python opcodes are atomic. But I’m not sure C library developers will really mind too much because they already worry about this kind of stuff.
JamesSwift 3y ago
I think multi-threadedness is already an intermediate level concept so maybe its not a big downside. In turn, the ones that understand and need the performance get it.
tedivm 3y ago
Only if the user explicitly uses threads. By default people can still approach their code in the exact same way they do. I imagine most users won't think about threads at all, but may relay on frameworks and libraries that take advantage of them under the hood.
qbasic_forever 3y ago
It's only more performance if you're using the threading primitives and spawning new threads, moving work to them to do in parallel, etc.--this isn't something any beginner will consciously be doing. It might actually be slower in regular single process use that 99% of python users use (since the GIL is there for a very good reason and synchronizing access to python's internal state doesn't just happen for free or without some cost somewhere).

Waterluvian 3y ago

I’m glad they’re very conscious about how easily this could turn into a Python 4 debacle. They’ll have to be intensely careful not to accidentally affect yes-GIL behaviour. All kinds of weird cases are possible if any sort of emulated GIL isn’t exactly like with a GIL.

miraculixx 3y ago
I am sure the intent is good. I am not so sure it is possible to avoid. They already say it could take 5+ years of having gil + nogil exist in parallel. For any tool builder that means their cost has just doubled for the next five years, at least. Why? Because people will want to use tools in either mode, no matter if it is deemed productive or experimental.
- slt2021 3y ago
  essentially the adoption of No-GIL Python will depend on: 1. In which version No-GIL will become default option in CPython 2. When that CPython version will come standard in LTS Linux distro 3. When all earlier LTS distros will go out of support 4. When companies switch from outdated to target LTS version of distro currently quite a lot of companies use python3.6 only because it comes standard with the Ubuntu 14.04.6 which happens to be the oldest LTS version - and companies have habit of migrating from out-of-support LTS version to currently-supported-oldest-LTS
  - pmontra 3y ago
    A customer on 18.04 just told me to wait another year and migrate their servers to 24.04 so they can stay there until 2029, or will that be 2030? They are on the standard 5 years LTS support, not the extended 10 years one.
travisjungroth 3y ago
I’ve seen no description of how this won’t be like 2 -> 3 except: 1. We don’t want it to be. 2. We’ll give up quickly if it is. Those are both important points. But there seems to be an important missing third piece of “and we’ll achieve this by…”.

vasili111 3y ago

What are advantages of non-GIL Python?

KMnO4 3y ago
GIL is a promise from the internal implementation (eg CPython) of Python that things will happen atomically within the Python interpreter. This means that when multiple threads try to access and modify Python objects at the same time, the GIL ensures that only one thread can execute Python bytecode at any given moment, preventing potential conflicts and ensuring data integrity. However, this comes at the cost of limiting the full utilization of multiple CPU cores for certain CPU-bound tasks. Non-GIL adds some complexity to the implementation and some risk when writing multithreaded code at the benefit of improving performance.
- fbdab103 3y ago
  At the current implementation, GILless is a performance regression[0], of 5-7% [0] https://peps.python.org/pep-0703/#performance https://peps.python.org/pep-0703/#performance
- slt2021 3y ago
  But people are not doing cpu bound tasks in native python (performance is a joke), it all comes down to calling a C library that is optimized for compute - what will be the change that GIL brings here?
  - AlphaSite 3y ago
    There is a JIT being built for Python, so performance is being attacked from 2 avenues, single threaded and multithreaded.
lostdog 3y ago
In GIL Python, you might think you could speed something up by multithreading, but it turns out you can't. The GIL will just run it serially anyways. No-GIL means it is possible to run things in parallel (without resorting to fancy C extensions).

valyagolev 3y ago

there's a lot of code I wrote (and saw people write) in Python over the years, conscious that noone will ever run it in threads (ofc it's possible, but typically pointless), thus going quite easy on things that wouldn't be thread-safe. this used to quite a comfortable stance. community ended up inventing other ways to share state, other ways to vectorize, other ways to avoid blocking on I/O, that might sometimes be annoying, but evolved to be quite reasonable for Python. giving up this stance? a lot of code is instantly a legacy, and a lot of it is a legacy people won't even know about before they notice the problems. and for what? i must say that i have no experience running Python without GIL so my idea of the ways things can be not thread-safe is purely speculative/borrowed from very different languages (that I finally moved on to long ago, thank god). so maybe i'm wrong, i misunderstand the impact, and all this code is just fine

miraculixx 3y ago
Well said. Thanks
valyagolev 3y ago
people in this thread mention that, for some reason, "even with GIL you still have to write thread-safe code", which is an admirable stance, but I don't think many people do it, because their webserver or whatever uses the many single-threaded processes model and they don't want to waste time on that
- miraculixx 3y ago
  Indeed. And the reason they use multiprocessing is bc they have learned that Python's multithreading is not a good option in cpu bound tasks. The blessing in disguise of course being that multiprocessing is also a shared nothing model, so (mostly) lock free programming is the default. Oth if you have a need for concurrently accessed shared memory/resources and need locks, it comes with an explicit cost. I think that's a good thing. In the future the default concurrency model will be shared everything free threading, and all hell might break loose. Hopefully not.
  - 3y ago

ggm 3y ago

Lots of C library code for decades carried man page warnings it was unstable for use in async, re-entrant and recursive contexts. We learned how to cope and incrementally re-entrant safe versions deployed without too much API instability. Maybe time has healed wounds and caused me memory loss of the pain of discovery you'd tripped over them. String parsing which tokenised in-place. DNS calls which used static buffers. Things which exploited Vax specific stack behaviour. I think the GIL has been a blessing and a curse.

pwdisswordfishc 3y ago
What is Vax specific stack behaviour?
neilv 3y ago
I remember scouring those C runtime docs, for every non-reentrant function. It might be what got me in the habit of checking docs when using some API that I know moderately well, just in case there's some important detail I missed before, or something had changed. Around that time, doing cross-platform C++, I got an early look at Java, with concurrency built in from the start, along with GC and various other nice features that were easier to use than C++, and I "knew" it was going to be huge. (But who knew that the MIS people would take over Java, when it seemed clearly targeted at non-MIS programmers, and now MIS people are stuck with the C++ syntax and verbosity, after coming from 4GLs, etc.) Then mainstream programmers picked up Python, which, IIRC, originally was an embeddable extension language, which was why it was simple. And for which the GIL made more sense.
- eru 3y ago
  > I got an early look at Java, with concurrency built in from the start, [...] and I "knew" it was going to be huge. And Java doesn't even have good (conceptual) support for concurrency. Compared with eg Erlang, Rust or even Haskell. But Java was still better at it than C or C++ at the time.
  - dboreham 3y ago

Systemmanic 3y ago

GIL: Global Interpreter Lock. Good explanation here: https://realpython.com/python-gil/ https://realpython.com/python-gil/

jmount 3y ago

Why would you even want a no-GIL Python? Java and C showed how much more effort it takes to maintain slower thread safe code for no real benefit. Parallelize at the fork level or at the isolated numeric library level.

qbasic_forever 3y ago
Yep I think over the next year a lot of python devs are going to learn threading isn't magic pixie dust that makes your code fast, and in reality is starts by making your code very unstable.
- miraculixx 3y ago
  I'm afraid that's exactly what will happen. Unfortunately the overarching sentiment will not be "multithreading is hard" but "Python has become really hard to work with"
commonlisp94 3y ago
Exactly. I think a lot of the negativity about GIL comes from a misunderstanding about forking processes. If python is being used as a scripting language, and spawning other tools, you're already getting free multi-core. A similar misunderstanding exists about SQLite and concurrency.. but that's a topic for another time.
- AlphaSite 3y ago
  Forking had a ton of its own downsides, it’s not a free lunch either, from poor ergonomics to communications overhead it works well for somethings and very poorly for others.
  - miraculixx 3y ago
    Yes, the same is true for free threading. Yet people assume free threading is free concurrency and that's the problem.

andrewstuart 3y ago

As a Python developer, what would be the benefit of no GIL?

deleted 3y ago
[deleted]
qbasic_forever 3y ago
Slightly faster performance when you write multithreading code correctly (much easier said than done). Very few python devs are actually running into this as a bottleneck day to day.

slt2021 3y ago

Naiive question: Who needs No-GIL when we have asyncio and multiprocessing packages ? never ever had a problem with GIL in python, always found a workaround just by spinning up ThreadPool or ProcessPool, and used async libraries when needed. is there any use case of No-GIL which is not solved by multiprocessing ? I thought Single threaded execution without overhead for concurrency primitives is the best way to high performance computing (as demonstrated by LMAX Disruptor)

miraculixx 3y ago
Some of the use cases advocating for nogil come from the AI/ML group of library builders, stating a need for free threading concurrency.
- pama 3y ago
  Agreed. Feeding the GPUs with multiple forked memory-hogging processes is no fun and leads to annoying hacks. And, yes, as per your other post, there could have been other solutions to this problem, some of which might have been better.
  - miraculixx 3y ago
    Yes but that's a very particular use case that could have been well served with a per gil thread and arena based memory for explicitely shared objects.
dragonwriter 3y ago
> is there any use case of No-GIL which is not solved by multiprocessing ? Anything that benefits from both parallelism and replacing IPC overhead with shared data between parallel tasks.
- slt2021 3y ago
  but it would incur overhead of concurrency control: mutex, locks, semaphores. I dont believe python will ever have atomic operations, even if it had - they still incur significant overhead for concurrency control. sharing state between threads is such a narow niche use case, this pattern is practically solved by memcached/redis for larger scale python based systems

nnx 3y ago

I hope this won't make Python's dependency hell even worse, but I'm not hopeful.

phkahler 3y ago
It's optional. Just keep using the GIL.
qbasic_forever 3y ago
Yeah it's going to be weird for some years where some libraries support no-GIL and others don't, while folks cry about the ones that don't support it holding them back. Like asyncio's introduction we'll probably see core stuff like http requests, file IO etc. all now have an entirely new permutation of libraries made to support non-GIL mode. This is going to get pretty spicy as stuff like http already has regular (blocking IO) and asyncio (non blocking IO) versions, so now do they need regular non-GIL and asyncio non-GIL versions too? Is the default for a library author going forward to be creating four permutations of your library with vastly different behavior in each of them? Yuck.
- miraculixx 3y ago
  import this ;)
- ies7 3y ago
  > while folks cry about the ones that don't support it holding them back. And someone may prefer to make NON GIL wall of shame/fame instead of directly contributing to those libraries

nicechianti 3y ago

[dead]

bjourne 3y ago

This can (and I think will) cause issues for C extensions because many are written without multi-threading in mind. Here is a small example which is unsafe if lst can be accessed from another thread: https://news.ycombinator.com/item?id=36649769 https://news.ycombinator.com/item?id=36649769 Note that the code may cause a context switch even today if the C code callbacks into Python bytecode (via a __del__ method) and the bytecode is long enough (100 instructions I think). However, that is extremely unlikely and much C extension code is not written with such situations in mind. People using C extensions may also rely on them executing atomically. For example, you could have a thread pool that posts and receives from a numpy array. Would work fine today but break without the GIL.

qbasic_forever 3y ago
Yep there are a ton of issues like that to be found, and unfortunately they will manifest as difficult to find and debug race conditions. This is why the proposal and work is to make non-GIL mode entirely optional and not the default. It just means for the brave few that flip it on and use it, be prepared to spend a huge amount of time finding and fixing subtle race conditions in decades of old python library code. The early adopters are going to be in for a lot of pain, or more likely they'll restrict their use of non-GIL processes to very specialized and dedicated processes that have as few dependencies as possible.
- miraculixx 3y ago
  The intent is to make no GIL the default eventually.
  - n2d4 3y ago
    I don't think this is true. There are fairly strong voices on both sides inside the community, at this time it's pretty uncertain. To quote Guido: >Let’s not blow it this time. If we’re going forward with nogil (and I’m not saying we are, but I can’t exclude it), let’s make sure there is a way to be able to import extensions requiring the GIL in a nogil interpreter without any additional shenanigans https://discuss.python.org/t/pep-703-making-the-global-interpreter-lock-optional-3-12-updates/26503/19 https://discuss.python.org/t/pep-703-making-the-global-inter...

amluto 3y ago

I’m not in love with some of the details. PYTHONGIL is an awkward tri-state. 0, 1, and unset all do different things. Wouldn’t some self-explanatory strings be better? PYTHONGIL=auto for the default, force-gil and force-nogil for the forced modes.

catnibbler 3y ago

Is it really too late to not do this ? The only reason to get rid of the GIL is to help threading, but that's not a thing we should be doing. Threads need to just die, and be replaced by something less idiotic. Seriously, having the CPU run fragments of your program at random, so that all the previously ordered pieces are now contending with each other and even themselves ? How can anyone not see that this is the stupidest idea in the world ?

Jabrov 3y ago
As opposed to?
- n2d4 3y ago
  In Python, asyncio and multiprocessing packages can get nearly the same or better performance for IO- and CPU-intensive tasks respectively as no-GIL multithreading (and are more performant than GIL multithreading), with only a tiny fraction of the pitfalls. For any use case where the last few percent matter, consider not using Python (which will be much much more significant). Regardless, we did somehow end up here, and there's plenty of multi-threaded Python code that would benefit from no-GIL, so I support the proposal just from a practical perspective. But when designing a new codebase, you'll almost almost almost always want to avoid Python threads, even with no-GIL.
  - usrbinbash 3y ago
    > asyncio ...is useless for CPU bound tasks. The event loop uses only one core. > multiprocessing ...relies on IPC and running actual system processes, both of which have alot more overhead than switching thread context and using shared memory. > For any use case where the last few percent matter, consider not using Python (which will be much much more significant). Here is an interesting question: If asyncio and multiprocessing already give us "nearly the same or better performance", then why is "use another language" such a common advice to escape parallelism-problems in Python? Because, curiously enough, the languages that are usually recommended for this (C, Go, Rust, C++, Java) all implement thread-based parallelism.

kalb_almas 3y ago

Even with improved support for parallelism, what role will Python have in the future if Mojo makes good on even half of its promises?

nologic01 3y ago
Mojo is not Python. The underlying pressure on the Python ecosystem is to transition to a post-Moore's law era and effectively become a HPC platform where the "same" code runs on a CPU, a GPU, multicore, clusters etc. Python may feel the pressure more than others because of the GIL and the fact it is used in compute intensive tasks more than others. But this major need to transition to easy and seamless HPC/heterogeneous computing is the same for all languages. The question is who will get there first.
- Too 3y ago
  Mojo is a superset of python, with goal to be able to run any python code and to import any python module under its own execution model, that runs magnitudes faster. Now, if that actually works as advertised, it would render python obsolete and become mojo instead, even if the authors don’t put it that way. Lex Fridmans podcast had an interview with one of the creators recently. Chris Lattner, who is also the creator of LLVM and Swift. Recommended listen for those who haven’t heard of mojo yet, if you have 3h to spare.

TX81Z 3y ago

But how will I waste thousands of person hours battling subprocesses now????

carabiner 3y ago

We are so back.

ahgamut 3y ago

"Python 4, but not really", because we want to squeeze out more multithreading performance and be cool again. Some questions from reading the OP: - How much does performance improve due to this No-GIL thing? Is it greater than 2x? For what workloads? - Do I have to compile two versions of every extension (gil/nogil)? I would prefer building extensions does not get any more complicated. - Can I automatically update my code to handle nogil? (a tool like lib2to3 or six)

donio 3y ago
The estimate in the PEP is that it will be 5-8% slower. Having to use more granular locks and atomic operations has a cost. https://peps.python.org/pep-0703/#performance https://peps.python.org/pep-0703/#performance

ram_rar 3y ago

This seems somewhat delayed, and it may be considered too little, too late. Python community had the chance to leapfrog and embrace alternative concurrency abstractions, such as go routines etc, but it appears that this opportunity was not fully utilized. After enduring the arduous process of migrating from Python 2 -> 3 and navigating the complex world of dependencies, my hope is that we won't encounter another nightmare of dependency management, forcing users to choose between GIL and no-GIL builds.

tgv 3y ago
Something akin to go routines won't solve the C-library problem.

raminf 3y ago

Remember the transition of text to Unicode? 32 to 64-bit? Intel to ARM? Y2K? No-GIL is a much smaller shift. It can follow the same transition path without radically breaking things. And if some things do break, there would be a well-defined way to handle those cases. We all somehow survived those. Glad to see forward motion on this. It will open up a lot more terrain that has been marked off as untenable. One of the things about early Swift that they got right was building breaking changes into the promise. Everyone knew where they stood and adjusted just fine. Sometimes I wish Python would take the same path.

viraptor 3y ago
I think that's a bit different. 32 to 64 - you could test whether it works. Same for arm. Same for y2k. Sure, maybe the testing wouldn't cover the failing case, but the testing you did would be deterministic. But here? Test all you want and the answer is: it's either correct or you haven't triggered the right race yet.
- samus 3y ago
  Yes, it is different because nobody would be forced to run the interpreter without the GIL. Applications where race conditions are unacceptable can keep using the GIL build. Even the `--disable-gil` build can be forced to keep using the GIL.
geewee 3y ago
I mean going from text to unicode did pose a huge problem for python specifically.
- asah 3y ago
  I have PTSD from that transition.
School-Cotton 3y ago
I’m not worried about the difficulty of migration; I’m worried that the end state might actually be worse than what we have now.

pyeri 3y ago

Let us wait and watch but I somehow feel that this no-GIL mode is just a band-aid solution to Python's performance problem. The cause goes deep inside the core of Python, it gradually came to this stage as more and more features got added to the language since the 3.x transition. I think new language features shouldn't just be added to provide syntactic sugars or coding shortcuts to programmers or just because a certain feature has become very cool (like lambda functions, for eg). I'm glad that the Python community has realized that performance is an issue and started working on things like no-GIL mode. People often say that Python's biggest strength is its readability and easy syntax but I disagree. Python's real strength is the enormous third party library ecosystem, popular packages like numpy, pandas, scikit, etc. which have almost become addictive in most data science projects. But now, people are thinking of other alternatives to these due to Python's performance issues. Other ecosystems like golang and rust are getting built at rapid pace and at some point, they will also have (more performant) equivalents of these packages if public shows enough interest.

ehsankia 3y ago
Hasn't python been getting much faster since 3.x? Where is your evidence that new py3 features is making python slower?

MrYellowP 3y ago

I'm going to miss the thread-safety non-GIL python offered. That being said, this is interesting. Can we get an in-python fork() mechanic ... please?

pritambaral 3y ago
> I'm going to miss the thread-safety non-GIL python offered. The old method — which is the GIL, or non-non-GIL — provides no thread safety to Python code. It only protects C code > Can we get an in-python fork() mechanic ... please? You probably want Multiple Subinterpreters: https://github.com/python/cpython/issues/84692 https://github.com/python/cpython/issues/84692

deleted 3y ago

[deleted]

dwaite 3y ago

I sure hope they decide to call execution of mixed GIL and no-GIL codebases "amphibious mode"

worik 3y ago

I am not a python programmer. What is the use case for this? Who needs it?

12_throw_away 3y ago
> I am not a python programmer I _am_ a python programmer. > What is the use case for this? > Who needs it? This can be answered with a simple user story: As "THE PYTHON STEERING COUNCIL", I want to "GET RID OF THE GIL", so that "PEOPLE WILL STOP WHINGING ABOUT THE GIL." To be fair, there's another group of people who stand to benefit. Namely, any python programmers who currently believe that "threads are an easy way to make my program go faster" will soon be the recipients of a valuable learning experience.
- miraculixx 3y ago
  Nice! ;)

kgeist 3y ago

Is the following possible? - library author marks their library "no-GIL" after making sure it's thread-safe without GIL - if the interpreter sees this metainformation, it temporarily disables GIL for the current OS thread while running the library's code - result: old versions of Python can still run no-GIL libraries under GIL, while new versions of Python allow to gradually remove GIL Or it's not how CPython works?

BGINBarbarian 3y ago
Afaik, nogil will be a compile flag, which means that when there are two builds, you separately compile Gil and nogil builds. They will be two separate programs/binaries/packages. It could be possible for something like conda to install both binaries, then run your program with the one that matches the library flags, but python itself could not do this (afaik).

dotnet00 3y ago

I'm looking forward to this, Python plays a fairly significant role in our scientific computing code and not having to have entirely separate processes will be very convenient for cutting down data duplication.

akdor1154 3y ago

Get exc's happening!ited, it

lraxny 3y ago

The ruling class in python-dev are populists who are not threading experts. Python is run by the wrong people. They will approve something if it serves a corporation. The submission here is likely CYA, so they can say that "they asked the community". There is no appreciation for people doing grassroots open source software. If Instagram can add another hack instead of switching to Java, it will be approved. It is important to remember that paid corporate developers will have job security every time new pain is introduced in the Python ecosystem.

miraculixx 3y ago
I have the same impression though I think its not intentional or otherwise ill intended.

hanselot 3y ago

for self in selfs:

JonChesterfield 3y ago

Exciting. Python is mostly written as C shared libraries that knew they had a global lock to rely on. Some of those do sufficiently simple things that they can run without any locking and all will be fine. Others will still need locking, but are now under pressure to run without the gil. Some of those are going to do DIY locking within their own bounds. Maybe what python has really been missing all these years is loads of ad hoc mutex calls scattered across the ecosystem. Data races and deadlocks introduced in the name of performance is not how I expected python to go out. edit: expanding on this pessimism a bit. Making C libraries written assuming a global lock thread safe is the sort of thing I'd expect concurrency experts to advise against and then make mistakes while implementing it. My working theory is that most people who wrote C extensions for python are not concurrency experts and are great programmers who won't back down from a challenge. The data-race/hang/segfault consequences of this combination look totally inevitable to me. Python application developers are not going to love the new experience and I'm thankful my products are not built on top of the python ecosystem.

tgv 3y ago
I think you're right. Making it an explicit opt-out, as is planned for the first stage, should be fine. Expecting to make it opt-in in 5 years seems too optimistic to me. It relies on all the library developers to fix their libraries (also the Python ones). That's tough work, and importantly, if done well, it will even go unappreciated: nobody will notice it. Many libraries have never had a multi-processing use case, others are so big that bugs are bound to happen, many of them subtle, so one guaranteed outcome will be unreproducible complaints and devs throwing in the towel. Opt-in will make people unhappy.
- Arbortheus 3y ago
  Surely if it goes well people will see their existing python codebases become more performant with no development required aside from updating some dependencies? Not nobody will notice it. It seems like it could be a great outcome for developers.
  - 3y ago

elisbce 3y ago

Seems these guys never learn from the Python 2 -> 3 mess. GIL to NoGIL is even worse. Most changes from Python 2 to 3 are syntactic, but GIL to NoGIL could require a complete redesign and rewrite. Either it takes another 10+ years migrating OR nobody with a realistic production codebase with 10k dependencies can turn this No-GIL thing on.

ksec 3y ago

It will be interesting to see how this will be executed. I think many in Ruby land wanted something similar but couldn't get some general agreement. Ractors tried and arguably failed. We have Samuel Williams basically the one person pushing very hard for Async changes. Ruby could learn a lot once this is done, but at the moment GIL optional in python seems to be a 2030 goal.

birdyrooster 3y ago

Soon I’ll be able to ditch golang

miraculixx 3y ago
Right about ~2033

samsquire 3y ago

Thank you so much Python core developers and steering council. Python is one of my favourite languages along with Java and C. I greatly welcome true multithreading in Python. I use both multiprocessing and multithreading in Python for different projects. See [0] for my multiprocessing example and python Threads for IO heavy tasks in [1]. But it would be far more efficient to use true threads. Threads can communicate any amount of data in a single atomic almost instant operation. Using the local loopback interface or multiprocessing or pipes, this is not possible. I am working on a multithreading architecture I call three tier multithreading architecture https://github.com/samsquire/three-tier-multithreaded-architecture https://github.com/samsquire/three-tier-multithreaded-archit... My goal is extremely scalable and performant servers but Python is probably the wrong job for that. [0]: https://news.ycombinator.com/item?id=36897054 https://news.ycombinator.com/item?id=36897054 (my description of my use of multiprocessing) [1]: https://devops-pipeline.com/ https://devops-pipeline.com/ (my use of multithreading)

fulafel 3y ago

How will this impact single thread performance?

miraculixx 3y ago
From the POC implementation the reports state ~5-7% if memory serves right.

kerkeslager 3y ago

Two major problems here: 1. There are some improvements worth breaking reverse-compatibility for, and removing the GIL is such an improvement. Whether the changes in Python 3 were worth making breaking changes for is debatable: certainly I don't see "print" being a function as particularly valuable. But the flipside is that the 2-to-3 transition was overblown by a vocal minority. I've transitioned more than 5 codebases from 2 to 3, and in most cases, there were few problems. Most problems were with codebases where previous developers had pulled in libraries for everything, resulting in an amalgamation of abandoned libraries, but these codebases run into problems even without the core language breaking compatibility. The answer isn't to flame your language into never breaking compatibility, it's to not import all of pip and expect that to be a sustainable strategy. The situation we have now is that the steering committee has received so much heat from the vocal minority that they're terrified to make breaking changes. But removing the GIL should be a breaking change. It's too fundamental to how Python works to not be. So they're trying to remove the GIL and make it not a breaking change, which is a bad idea, because it is ultimately going to be a breaking change. It would be much better to admit this is a breaking change and start working on the transition plan, than to try the impossible task of making it not breaking because you're too terrified of your users to admit the truth. We've already seen this in Python 3.11 which broke code in my codebase. The changes to fix the breakage weren't hard, but I would have liked better communication that this might happen. But I also understand why this was hidden in a deprecation warning in a minor release rather than publicized, because the Python team is probably tired of being flamed for making breaking changes. 2. The more fundamental problem here is that a lot of other features of Python were built around the GIL. Most obviously, the async paradigms makes sense largely because of the GIL. Sans-GIL, it looks like in retrospect a send/recv actor model a la Erlang would have been a much better way forward. It's not really possible to reverse this, and this might be pushing Python toward a less cohesive set of features that don't really make sense together. This makes it feel like this is too little too late.

miraculixx 3y ago

The creator and lead maintainer of SQLAlchemy, one of the most popular and most used Python libraries for accessing databases (who doesn't?) gave a rather interesting response to PEP703. > Basically for the moment the GIL-less idea would likely be burdensome for us and the fact that it's only an "option" seems to strongly imply major compatibility issues that we would not prefer. (...) > Adding an entirely new mode of operation to cPython that's optional would be an enormous burden for us as far as ensuring we use APIs appropriately, adding support, testing, we would have to spin up new test workers to test SQLAlchemy in both modes of operation, we would be getting strange new race condition related issues reported https://github.com/sqlalchemy/sqlalchemy/discussions/10002#discussioncomment-6252988 https://github.com/sqlalchemy/sqlalchemy/discussions/10002#d...