28 ms·

If PEP 703 is accepted, Meta can commit three engineer-years to no-GIL CPython

656 points by bratao 3y ago

scope54 3y ago
[dead]
stanislavb 3y ago
[flagged]
- noSyncCloud 3y ago
  Well, "put your money where your mouth is" would be more apposite. I commend them for volunteering to contribute in this way. A rising tide and all that.
- dcchambers 3y ago
  Isn't this just how most open source software with enterprise customers operate? Big companies pay (money or with developer time) in order to gain support and to steer the product to add features they want. The open source produce lives on, developers get paid for their work, big co gets features they want, and everyone lives a happy life.
- kzrdude 3y ago
  Microsoft is currently having a multiple person team work on the faster cpython project. That's "money talking" in the same sense.
kzrdude 3y ago
I believe you want to link to https://discuss.python.org/t/a-fast-free-threading-python/27903/99 https://discuss.python.org/t/a-fast-free-threading-python/27... (comment #99, the most recent right now.)
jsnell 3y ago
The editorialized title "Meta pledges Three-Year sponsorship for Python if GIL removal is accepted" seems misleading at best. The actual wording was: > support in the form of three engineer-years [...] between the acceptance of PEP 703 and the end of 2025 It seems much more like them pledging engineer time from Meta employees to work on this project than sponsorship, not a monetary sponsorship like the title implies.
- o1y32 3y ago
  Yep, the original comment was very carefully worded.
- meitros 3y ago
  And also in direct response to a comment from GvR, not something out of the blue
  - derbOac 3y ago
    Yes, and the comment is to request help essentially: "it would be great if Meta or another tech company could spare some engineers with established CPython internals experience to help the core dev team with this work."
- deleted 3y ago
  [deleted]
- hn_20591249 3y ago
  Offering dedicated specific CPython resources (aka. enginneering hours) is worth more than a monetary sponsorship in my view.
  - xcdzvyn 3y ago
    Right, but that's not the topic at hand. For better or for worse the title is a little misleading.
  - smeyer 3y ago
    That also depends on the scale of the monetary sponsorship, though. If I heard something like "Meta/Google/Whoever is the main sponsor of Python for the next 3 years", I'd assume (perhaps incorrectly) much more money per year than it takes to hire a single engineer. On the other hand, someone just saying "sure, we'll do the silver tier at your next few conferences" is worth a whole lot less than one engineer. Regardless, the previous commenter's point stands that the title could be a lot more informative.
  - 3y ago
gautamcgoel 3y ago
This is potentially problematic. It creates a conflict of interest: will the GIL proposal be accepted based on technical merits and potential benefits to the Python community overall, or just because the Python foundation wanted money? The problems that Meta faces in production are not necessarily the problems faced by every Python developer. In particular, Meta might value performance more than backwards-compatibility, while other Python users might feel differently. If Meta were to offer unconditional support, that would clearly be good for Python; attaching conditions to their support makes the situation trickier to navigate.
- draw_down 3y ago
  [dead]
- jsnell 3y ago
  Your premise is incorrect, as this is not a promise of money.
- bob1029 3y ago
  What is Meta's end game with Python? Do they genuinely just want a stable build without GIL because of some cranky in-house code piles, or is this the first step towards a bigger mission to wrangle an entire ecosystem?
  - AlphaSite 3y ago
    They use Python as the basis for instagram, which is a large growing service.
    - bugglebeetle 3y ago
      And now Threads as well.
  - trollied 3y ago
    Would you they rather used these man years to implement it behind closed doors & never release the build? They use Python. They want to donate engineering time. They think this is a good idea. Why does there have to be a sinister motive?
a1o 3y ago
It's three engineer years until 2025, and it's just a person mentioning on the discuss board. It sounds a bit weird to throw something like this in a public forum.
- jsmeaton 3y ago
  Why weird? The request was made there. The discussion on the PEP is there. And the person answering is a core Python dev and part of the Python team at meta/insta. Their team wants it, and is offering hours to help get it done. Is this not what everyone wants from businesses using OSS?
- SoftTalker 3y ago
  So they'll put 36 people on it for a month in November 2024?
andrewclunn 3y ago
Evil response. Say, "Sure!" and release python v4 with their feature request, and watch the python split wars happen all over again >:-}
- jowea 3y ago
  I genuinely wonder if this issue would cause a fork. At least a long term maintenance that keeps the GIL.
  - kzrdude 3y ago
    Python is closer to C than we all like to imagine, in more than one way. Lots of access to low-level libraries. Long history of writing modules in C. And little in actual memory safety protection more than relying on programmers to please not write bugs in their C or ctypes code. Philosophically, Python is close to C in the sense that low-abstraction interfaces to system functionality (file descriptors, memory) exist. Numpy allows access to uninitalized memory and you can manipulate how numpy uses memory (mmap, shared memory, sharing memory between objects). Ctypes allows access to malloc and dereferencing dangling pointers. This is not exactly normal Python, but it's inside the realm of the possible in Python. All of this makes me worried that the challenge of "free threading" is quite large. I wonder if the subinterpreters solution offers a safer route. At least it's not pulling off the GIL band-aid all in one go.
    - formerly_proven 3y ago
      Can’t even call print or logging from signal handlers (that’s UB in Python), despite being bounced off of the VM.
    - kzrdude 3y ago
      On other hand, allowing access to free threading would be a straight-line continuation of this culture: just make that feature available. ("we're writing system code in a high level language.")
brunes 3y ago
They committed three person-years, not three years. This project would need dozens of person-years over a three year period. Also a comment on Github is not a binding support contract. Meta executives could deprioritize this project at any time... hell the person making the commitment could already be laid off, we have no clue. As someone who worked in big tech for a long time, trust me - it needs to be in writing with an exec signature.
Agingcoder 3y ago
It’s an interesting debate ( money aside ). In the past 15 years, at least to my eyes, one of the most important changes in soft eng culture has been the now systematic search for correctness. Systematic, organized, large scale Testing is one side of the coin, but the real value , and significantly more important change to me is guarantees/proofs : static analysis, stronger type systems, etc. So type annotations in Python, typescript, rust instead of c++, etc. Tools as well : golang race detector, infer, coverity, pvs studio, code peer (Ada)/spark, compcert, etc. In this particular case, I understand that removing the Gil would create potential new risks ( but provide better performance) and although tooling is mentioned, it’s not officially part of the plan, so it feels like a regression of some sorts.
- klysm 3y ago
  It might be worth it though because somehow python had ended up being the lingua Franca in a many applications where performance matters a great deal (ML, scientific applications, etc). I don’t think the performance benefits for something deployed at such a large scale should be understated.
  - local_crmdgeon 3y ago
    Indeed and to add - the environmental impact of Python’s speed is nontrivial and growing
    - klysm 3y ago
      Although you are almost certainly correct, I’m curious if there is a case where faster doesn’t mean more power efficient I.e. more concurrency but more power overall
      - H8crilA 3y ago
        Concurrent execution is ~always less power efficient than serial execution. I have no idea what the parent comments are talking about. For almost any work X with time to run on a single core T it will run on two cores in time larger than T/2, and on three cores in time larger than T/3, ... This is due to synchronization overhead (e.g. networking, locks, delays) and also often due to shared resources getting saturated (e.g. VRAM on a GPU). That is unless in the serial execution you still have to pay for some resources that are unutilized.
synergy20 3y ago
So generous! The FAANG etc failed me for anything open source sponsorship related. Their business depends on it, they made a fortune out of it, yet they donate little or nothing to it, or worse, they forked it and was reluctant to upstream anything. pick Amazon randomly, it went from exploiting to rip-off in my opinion, thanks to its boss , who sails on a luxury yacht and asks all his employees to be frugal. they all look similar to me as far as supporting OSS goes.
- nradov 3y ago
  Meta contributes a huge amount to the open source community. https://opensource.fb.com/ https://opensource.fb.com/
  - stevefan1999 3y ago
    React alone is one of the biggest feast Meta brought to open source community, and shaped the web from monolithic pages (back then PHP and jQuery is the majority) towards modular components design. Later they even introduced functional programming paradigm in the mix. Next.js exists too which mashed up PHP/Ruby style with React.
- acedTrex 3y ago
  In terms of companies that rip off open source and do not give back meta is certainly one of the more active "give back" companies. React/Native, docusaurus, buck, pytorch, rocksdb...
  - synergy20 3y ago
    yes some big companies did open source projects and Meta is a good role model, for many those OSS projects, they work for the companies themselves first then the community, though they are indeed still 1 million times better than closed and proprietary code. I'm mainly referring to long standing fundamental projects that made the rest projects possible, not those projects that are created and managed by the big companies themselves.
dig1 3y ago
Whatever happens, I'm hoping we won't see another 2to3-like migration. I moved from Python a long time ago due to its multi-threaded limitations (among other things) to Java and JVM, and I really appreciate the stability the JVM team tries to maintain. Things are not perfect, but I'd take stability/compatibility over perfection any day.
- whoknowswhat11 3y ago
  Could not agree more. The purposeful unnecessary breaking stuff was maddening- and then being lectured at like you were an idiot more so. No more u”” for you!
  - atdt 3y ago
    There is zero chance of that happening. Guido van Rossum (and other key figures in the Python community) have spoken very candidly for years about the mistakes they made in the 2-to-3 migration and their decisions in the year since have demonstrated their commitment to not repeating these mistakes.
    - blamazon 3y ago
      I was curious about these comments and did a small web search. I found a video interview from May 21, 2021 [1] and have pasted some excerpted quotations from it from Guido van Rossum below for others who are curious. “Python 4, at this point whenever it’s mentioned in the core development team, it is very much as a joke… We’ve learned our lesson from Python 3 vs 2, and so it’s almost taboo to talk about a Python 4 in a serious sense.” [...] “I normally talk about that as a mistake, because Python was more successful than the core developers realised and so we should have been much more aware and supportive of transitioning from Python 2 to Python 3” [...] “I’m not thrilled about the idea of Python 4 and nobody in the core dev team really is – so probably there never will be a 4.0 and we’ll just keep numbering until 3.33, at least” [...] “We now have a strict annual release schedule, so after 3.10 will be 3.11 and after that will be 3.12, and so forth. We can go up to 3.99 before we have to add another digit. Adding another digit is not completely trivial, but still much better than going from 3 to 4." [1]: https://www.youtube.com/live/aYbNh3NS7jA https://www.youtube.com/live/aYbNh3NS7jA
oneTbrain23 3y ago
I think at this point it is better Meta to ditch python and invest in a new programming language that mimics exactly wording for wording of python but without GIL. Google did it with their Carbon for C++, Go for C/D/C++. Microsoft even wrestle with Java for .NET and at one point their J++ 2 decades ago. Meta shpuld create their own. Maybe dump their resources into Modular. Python at this point is basically a C++ with a hotch potch of features and codebase. Start from clean like Mozilla Rust would help entire programming a lot than invest in a niche subset feature of Python which they dont have any control at all (I am speaking from corporate point of view). Python is like Perl, it will continue to have its place even decades later to be generic or niche for AI. But the rest of us may be moving on to something more specialized and cleaner like Rust, Ruby, Modular, etc.
- mlrland 3y ago
  Agreed, they should port their AI stacks to a functional language. It looks like these efforts are designed to prop up Python for the scientific stack.
- moonchrome 3y ago
  migrating from python to Ruby for something cleaner ?!
  - T-A 3y ago
    From the top post in that thread: Most of this work has been on Javascript, which is single-threaded and less mutable than Python, but PyPy has also made some significant contributions. PyPy has a GIL. There is also work on Ruby. Ruby is even more mutable than Python, but also has a GIL. Work on Ruby mirrors that on Javascript.
    - dragonwriter 3y ago
      Ruby's GVL is no longer truly global because of Ractors, which are a different approach to reducing the impact of a global lock.
- 3y ago
mlrland 3y ago
[flagged]
elaus 3y ago
The title is highly editorialized and links to a comment that has nothing to do with the sponsorship. Direct link to the comment, where Meta offers to commit to working on this issue for 3 person-years: https://discuss.python.org/t/a-fast-free-threading-python/27903/99 https://discuss.python.org/t/a-fast-free-threading-python/27...
pixelgeek 3y ago
I am curious how much of the python community the GIL affects? And is Facebook's interest related to AI performance?
- qbasic_forever 3y ago
  Almost every single data structure access in python, even reading a dictionary item, at some level depends on the GIL for true correctness right now. It is very deeply embedded in cpython.
  - pixelgeek 3y ago
    I didn't phrase that well. How much of the Python community is writing code that would be positively affected by the removal of the GIL? The entire debate seems to be for code that strikes me as being far and away from the typical Python programmer.
    - netheril96 3y ago
      Every ML engineer will be impacted. Web server probably less so.
      - singhrac 3y ago
        I think it’s the other way around? I haven’t run into any ML code that could be multithreaded that wasn’t written in C++, but have often run into server tasks that could use a polling thread, etc. All the ML code is written in lower level languages and that’s very unlikely to change, GIL or no.
        brrrrrm 3y ago
        driving multiple GPUs on the same node is better handled by threads. Python is forced to use multiprocessing
        3y ago
qbasic_forever 3y ago
The GIL problem won't be solved by throwing engineer hours at it (not even Meta engineers). Fundamentally every single piece of python code ever written will have to stop and now worry about potential race conditions with innocent things like accessing a dictionary item or incrementing a value. It's a massive education and legacy code problem at least on the same scale as the python 2 to 3 migration. I honestly don't think the community is ready for this change and don't expect to ever see stock cpython drop the GIL--perhaps there will be a flag to selectively operate a python process without the GIL (and leave the onous on you to completely test and validate your code works with potentially new and spooky behaviour).
- wuiheerfoj 3y ago
  Is this not exactly what the PEP-703 is?
- mountainreason 3y ago
  I dont get this. Just because you don't have the GIL doesnt mean that your previously single threaded code is now multithreaded and stepping on itself.
  - 411111111111111 3y ago
    From previous discussions it's my understanding the c integration is going to be the cause for the issues. From a python perspective it wouldn't necessarily be a big change, but everything can branch out to c, and there you're going to get in trouble with shared memory.
    - dwaite 3y ago
      The most significant impact of this change is that python threads can run at the same time. Before, calls to C API were essentially cooperative multithreading yield points - even if you have 100 python threads, they can't run concurrently under the GIL. 99 are blocked waiting on the GIL. C extensions have always been able to use real threading. But now there is no GIL to synchronize with the python interpreter on ingress/egress from the extension.
Aachen 3y ago
[flagged]
- aardvarkr 3y ago
  The GIL is Python’s global interpreter lock which bottlenecks performance in multithreaded applications by locking variables. They’re working on removing it but it introduces race conditions if programmers aren’t aware of the change.
- londons_explore 3y ago
  The code is here: https://github.com/discourse/discourse https://github.com/discourse/discourse I'm sure they'd welcome a patch to fix the forums.
- zdragnar 3y ago
  Do you have JavaScript disabled? It is a deep link into a very, very long forum thread. Instead of pagination, comments outside of a certain window are loaded as you scroll. https://discuss.python.org/t/a-fast-free-threading-python/27903 https://discuss.python.org/t/a-fast-free-threading-python/27... Should take you to the first post, which is an overview of the proposal problem and potential solutions. Mobile Chrome renders the page just fine. No idea about what other WebView you're using, but JS definitely needs to be enabled to load additional content. In short, GIL is the global interpreter lock, something that is innocuous in single threaded software but a bane for performance in a true multithreading environment. I'd recommend reading up on it elsewhere if you're not familiar with it, as the post elides a lot of detail (the audience is the forum is, after all, people already familiar with python internals). "nogil", therefore, is a shorthand for CPython running without the global interpreter lock. The crux of the proposal is a discussion on how to achieve it without making large sacrifices to reliability or performance in single threaded scenarios.
  - Aachen 3y ago
    JavaScript enabled. Like I said, first site that ever behaves like this; three quarters of the Internet would be broken if I didn't have JS. (And Firefox and archive.is also run JS afaik) > No idea about what other WebView you're using, Android default, so also chrome-like, just not the proprietary Google Chrome browser > "nogil", therefore, is a shorthand for CPython running without the global interpreter lock. Ooh, I should have realised what nogil means. If this had been in the headline with capitalisation like noGIL, I wouldn't even have needed to click to understand what it is Facebook wants to work on. Thanks!
punnerud 3y ago
PEP 703 will add the option to disable GIL (default is on). More context here: https://peps.python.org/pep-0703/ https://peps.python.org/pep-0703/
- simonw 3y ago
  That PEP had not yet been formally accepted. That's what this thread is about.
sheeshkebab 3y ago
20+ years later, and billions of lines or python code later, the GIL discussion is still there. Kind of an amazing mess of a problem… mainly shows the priority of python being a ducktape type solution from the start.
mkl95 3y ago
Don't Meta maintain their own fork?
- tekknolagi 3y ago
  I previously worked on Cinder. Maintaining a fork is hard and the goal is not to do that.
bjourne 3y ago
Latest decade in software engineering indicate that multi-processing is much preferable over multi-threading. It's the architecture Edge, Firefox, and Chrome uses. So the question is what use cases multi-threading address that are not already covered by multi-processing? The memory overhead that multiple processes cause is relatively insignificant on recent machines with 32GB+ of ram.
- SR2Z 3y ago
  Tons of use cases! There are lots of concurrent algorithms that use locking and shared memory instead of message-passing. Matrix multiplication or tree search come to mind.
  - bjourne 3y ago
    Parallel blocked n^3 matrix multiplication doesn't use any synchronization primitives (short of join). The processes read from the same input matrices, but write to non-overlapping regions of memory. This is easily accomplished using posix shared memory. Indeed, this is how it is done when the matrices to be multiplied are too large to be handled by single worker nodes.
- jvanderbot 3y ago
  I don't think anyone is unilaterally going to move to multiprocess as a programming paradigm. Web browsers have their own reasons for using Multi-process, including security from memory isolation, resilience against crashes in the client side code, killing individual tabs, and so on. I'd wager the vast majority of programs being written that need concurrency or parallelism still use multi threading or SIMD.
  - kuchenbecker 3y ago
    This must be browser specific, as servers still use threading. The 32GB mentioned is very small as well, we run up to 1.5TB nodes.
    - 3y ago
Kwpolska 3y ago
> If PEP 703 is accepted, Meta can commit to support […] between the acceptance of PEP 703 and the end of 2025 Meanwhile, the Steering Council is dragging their feet, even though so many people in the community have chimed in their support for nogil being a thing (in the linked thread and two others). https://github.com/python/steering-council/issues/188#issuecomment-1575106739 https://github.com/python/steering-council/issues/188#issuec...
- lagt_t 3y ago
  This is a decision with huge ramifications and the PEP was submitted only 5 months ago. Caution is welcomed here. Specially with PEP 684 around the corner.
  - Kwpolska 3y ago
    As @colesbury said in the GitHub thread: > The PEP was posted five months ago, and it has been 20 months since an end-to-end working implementation (that works with a large number of extensions) was discussed on python-dev. I would expect the SC to be active participants in the community, including the python-dev mailing list, so they should have known what this change means by that point.
gexaha 3y ago
Sorry, stupid question, can someone tell, please, how do other interpreted languages deal with problem similar to GIL or noGIL?
- ddtaylor 3y ago
  I think comparing it to something like nodejs the way they work around the issue is that almost all their code is written in JavaScript itself. Python has a different model where a very large amount of the code is written in c and python itself is just a glue.
  - rcme 3y ago
    A huge amount of NodeJS is written in native code. JS is single threaded. Async work doesn’t work without native code. JS doesn’t need a GIL because it only has one thread.
- aardvark179 3y ago
  You use smaller scale locks as and when you need them, and you spend a lot of time to carefully implement core threading constructs and similar to make sure they are correct. Most of the time in an interpreter you’re iterating through the byte code for a function, and mutating variables. It doesn’t matter if two threads are executing that same byte code, it only matters if they are mutating the same object. That’s not to say there aren’t some operations that need coordination across all threads. For that you implement safe points so you signal that something has to be done, wait for all threads to reach a safe point, do the work, and then release the threads again. You can often be even smarter about this and avoid stopping all threads at once but instead stagger things. Allocation and GC you can make more thread local to avoid stopping the world too often.
- csmpltn 3y ago
  The GIL is a conscious trade-off between contention/performance against a simpler code. Without the GIL, you'd still need to use different locking/synchronization mechanisms to ensure thread safety (if required), but they'd be more nuanced and spread over the entire codebase (complicating the backend).
runevault 3y ago
I can't even imagine how many engineering years it would require to fix just the most used libraries that expect the gil to exist. I assume 3 years wouldn't even cover the actually interpreter, throw in the library piece and how is this useful?
- singhrac 3y ago
  I can’t imagine you’ve read the proposal with a comment like this. The interpreter is already patched (twice in the proposal, for two different versions of Python), and Sam Gross has personally already patched many commonly used Python libraries. Here’s numpy patched, a mess of C and Fortran written for high performance code: https://github.com/colesbury/numpy/commits/v1.24.0-nogil https://github.com/colesbury/numpy/commits/v1.24.0-nogil This comment is the definition of FUD.
santiagobasulto 3y ago
There's a great talk by David Beazley (I don't remember which one) that he basically explains that removing the GIL isn't difficult at all. After all, it's just one lock. The issue is all the libraries and packages that were built around it. It's now been YEARS of building on top of the GIL. So anyways, PEP 703 is a a nice effort, but I doubt we (everyday mortals) can enjoy it. Meta, and big companies with a specialized team might be able to exploit it by making sure their entire stack is GIL-free. EDIT: My bad, the talk is from Larry Hastings: https://www.youtube.com/watch?v=P3AyI_u66Bw https://www.youtube.com/watch?v=P3AyI_u66Bw
- kzrdude 3y ago
  Sam Gross has worked vs numpy and other modules to make it work well in practice
- thelastbender12 3y ago
  > So anyways, PEP 703 is a a nice effort, but I doubt we (everyday mortals) can enjoy it. I'd suggest we can be more optimistic. There is a lot of python, regular users write daily, where we delegate orchestration to established libraries - asyncio/web-frameworks/pytorch. The GIL limits how much they can parallelize your code, and its removal will help with that.
- tomwojcik 3y ago
  2016. A lot has changed since then and AFAIK numpy and other most popular libs with bindings in C have an experimental branch that is already nogil compatible. Not saying he isn't wrong, though.
- klysm 3y ago
  “Just one lock” is kind of misleading if decades of software has accumulated that is predicated on its existence
- gjulianm 3y ago
  > Meta, and big companies with a specialized team might be able to exploit it by making sure their entire stack is GIL-free. Not really. Most of the popular libraries will have nogil versions ready for sure (numpy, pandas, pytorch, etc). Server applications will probably benefit from being able to serve multiple requests in a real multithreaded environment without many changes (in fact, I bet a lot of HTTP libraries will see simplifications due to not needing to deal with processes for real parallelism). Even packages without changes will probably have at least a small degree of thread safety (for example, two instances of the same object should be independent and could be used in different threads) that allows users to still leverage parallelism.
meindnoch 3y ago
[flagged]
js2 3y ago
Removing the GIL will not break the vast majority of existing Python code. Here's the backwards compatibility section of PEP 703: https://peps.python.org/pep-0703/#backwards-compatibility https://peps.python.org/pep-0703/#backwards-compatibility That section is short and I encourage you to read it in full. Here's what it says about how removing the GIL affects existing Python code: • Destructors and weak reference callbacks for code objects and top-level function objects are delayed until the next cyclic garbage collection due to the use of deferred reference counting. • Destructors for some objects accessed by multiple threads may be delayed slightly due to biased reference counting. This is rare: most objects, even those accessed by multiple threads, are destroyed immediately as soon as their reference counts are zero. Two places in the Python standard library tests required gc.collect() calls to continue to pass. That's it with respect to Python code. Removing the GIL will require a new ABI, so existing C-API extensions will minimally need to be rebuilt and may also require other changes. Updating C-API extensions is where the majority of work will be if the PEP is accepted. This will be an opt-in feature by building the interpreter using `--disable-gil`. The PEP is currently targeted at Python 3.13. This is nothing like the Python 2 > 3 transition.
- Waterluvian 3y ago
  which python which python3 which python3nogil
  - echelon 3y ago
    venv, virtualenv, pipenv, pyvenv, venvwrapper, conda, ... Python4 needs a hard reset.
    - whalesalad 3y ago
      those are all means to the same end. venv == virtualenv virtualenvwrapper is ancient not rly used anymore pyenv is a third party tool that makes some of this easier, notably around creating more than just a virtual env in that you also choose the Python version. Python is not hard to deal with in this regard I think people are just uninformed.
_a_a_a_ 3y ago
> Fundamentally every single piece of python code ever written will have to stop and now worry about potential race conditions Except for every single piece of python I have ever written which will continue to work just fine.
deleted 3y ago
[deleted]
TheRealPomax 3y ago
As someone not particularly tuned into the Python ecosystem, what is "nogil", though?
- mehdix 3y ago
  no GIL (Global Interpreter Lock)
  - TheRealPomax 3y ago
    That covers the "no" part, what's a global interpreter lock?
    - charcircuit 3y ago
      It is a global lock that is required to run the interpreter
      - TheRealPomax 3y ago
        Cheers. That does sound like it would impair actually being useful on multicore, multithreading cpus (which of course has been all of them for basically the last two decades)
- foundart 3y ago
  no Global Interpreter Lock
  - foundart 3y ago
    Its presence makes it difficult for python to run multi-threaded.
nocman 3y ago
Might be worth changing the title to "no-GIL". My first thought was "What is nogil CPython?" - thinking it was some specialized fork of CPython. I guess you could say that is technically true. I was previously aware of the GIL in Python, yet it still didn't occur to me immediately.
kkirsche 3y ago
Seeing so many comments about how hard it is to just break compatibility and upgrade is sad. Instead of just throwing our hands up and saying it’s too hard, we could adopt the model the JavaScript ecosystem has seen more of which is codemods that upgrade the code for us. If as a community we invest in those tools and make them easier to build, the cost of upgrading goes down and the velocity of high-impact changes can increase.
- inglor 3y ago
  TC39 has a famous "don't break the internet" mantra. Even the leeway that Python has with deprecations/features JavaScript doesn't. It's versionless, code automatically gets updated to whatever the browser is using. JavaScript evolves quickly but so does Python! (Note that your approach is exactly what they said in the 2 to 3 transiton btw with a special tool that didn't work too well)
  - kkirsche 3y ago
    That’s not what that library was in my opinion, it was a compatibility layer not a rewriting tool which is what I referenced. Having a layer in between simply prolongs the issue and creates many types of problems based on adoption or not. On the other hand, when rewriting you can apply that either as an author or as an end user depending on the quality which meaningfully allows for different results.
- VWWHFSfQ 3y ago
  I'm not sure what "codemods" means. Just static analysis code changer? Python is so highly runtime dynamic I'm not sure a tool is even possible to upgrade behavior, preserving correctness and intent (bugs and all).
  - twosdai 3y ago
    Not the poster of the question, But I think they're referencing the litany of transpilers and repackagers which exist for js. So you can add new features and then still have it run on really old systems like internet explorer 9 if you need to. This has problems obviously and in my opinion for python it would be preferable. My reasoning being that if you need your code to work on an older system being able to write and use current syntax is preferable to not, and the hard bifurcation that python did with 2 to 3 and now potentially with 3 to nogil seems to me just to break apart the ecosystem more.
resonious 3y ago
It's crazy how much work we put into trying to speed up these scripting languages. It's the same with Ruby. Shopify spends tons of dev resources on making JIT and stuff.
- pkkm 3y ago
  What do you find so crazy about it? Dynamically typed languages like these can be fast. It has already been demonstrated with Common Lisp and, more recently, JavaScript. Not only that, but LuaJIT has shown that you don't need impossibly complicated techniques or man-decades of effort to get very good performance. In Python's case, the main obstacle to improving the implementation isn't any feature of the language itself, but the giant ball and chain that is the C API.
hgs3 3y ago
PEP 703 mentions the multiprocessing module which I used recently with great success. It is essentially message passing parallelism, i.e. the actor model. I would think even with the GIL removed message passing is still the best approach for a higher-level language, like Python, to handle parallelism as it is conceptually simple and lock free. The primary disadvantage of the multiprocessing module is it uses separate processes which means my resource heavy Python extension needs to be duplicated multiple times in memory (at least on Windows). I think the move to supporting threads means the module could leverage them instead of separate processes, avoiding the need to duplicate C extensions in memory, and thereby reducing the overall memory pressure on a system.
- packetlost 3y ago
  I agree that message passing can be a really good choice. The problem is the overhead of passing large messages can be really substantial. In general, you'll need to store messages in memory 4x per message (at least temporarily): once on each end for the Python representation and the serialized "on the wire" representation. There's also the issue with `pickle` generally being a horrible serialization format and being the default. There are ways around this, Python has a rather rudimentary and archaic shared memory subsystem[0] that can make this much more efficient. On the other hand, the Python multiproccessing sync primitives actually work over a network with almost no code changes, so you can horizontally scale with little effort... but then you're paying the serialization and network overhead, so ymmv. [0]: https://docs.python.org/3/library/multiprocessing.shared_memory.html https://docs.python.org/3/library/multiprocessing.shared_mem...
- shepardrtc 3y ago
  Multiprocessing is great. Very easy to use and with the Manager(), passing data is easy enough, though very "slow" relatively speaking. It has to serialize the data, send it to the Manager process, then send to all the processes (I believe), and then deserialize it. Perhaps this nogil update can speed that up?
- tga_d 3y ago
  I have no experience with Windows, but at least on Linux, if the forking is handled intelligently (namely, late enough that identical assets don't need to be re-written), duplicated memory should be handled by Copy on Write.
sanket1729 3y ago
Just to clarify, this is three engineer years. Meaning a cumulative of 3 years over all engineers. I fail to see why this is a big deal. Don't big tech companies contribute much more to python FOSS
Animats 3y ago
Why waste effort on speeding up the old CPython interpreter rather than working on PyPy, an actual compiler? [1] "On average, PyPy is 4.8 times faster than CPython 3.7" [1] https://www.pypy.org/ https://www.pypy.org/
- slekker 3y ago
  What is the catch with PyPy? If it was a drop-in replacement for CPython, wouldn't everyone choose it as the de-facto version of Python?
  - cpburns2009 3y ago
    Some c modules are incompatible with PyPy. Two common ones are psycopg2 (PostgreSQL driver) and pyodbc (ODBC driver). There are alternatives that work but they don't have quite as many features (psycopg2cffi and pypyodbc). Ansible also runs slower in PyPy than CPython.
    - jdsalaro 3y ago
      > Ansible also runs slower in PyPy than CPython Do you know the reason?
      - cpburns2009 3y ago
        I tested this with a playbook that installs a set of scripts and dependencies on a server. In all there's ~30 tasks. It takes ~1 minute using CPython 3.10 and ~1.5 minutes using PyPy 3.10 (v7.3.12). Ansible says libyaml is installed in both runtimes so that's ruled out. I wonder if it's the difference in interpreter start-up time, and it accumulates over time as Ansible starts so many Python processes as it runs its tasks.
  - aeyes 3y ago
    It's hit and miss. Sometimes I get almost no improvement and sometimes I get 10x. But the slow warmup and up to 3x memory use (in my experience) really make me prefer CPython unless I have a very specific problem.
stainablesteel 3y ago
i get that it would feel nice to have real multithreading, but if i want real multithreading with python i just use xonsh to pipe in bash insert bell curve meme
BiteCode_dev 3y ago
This is a delicate issue. As guido stated (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...): > If there’s one lesson we’ve learned from the Python 2 to 3 transition, it’s that it would have been very beneficial if Python 2 and 3 code could coexist in the same Python interpreter. We blew it that time, and it set us back by about a decade. So it's not so easy to decide to go with again 2 different versions of Python. I understand how caution they are. However, this commitment from Meta, complemented with MS financing Guido, and the quality of Sam Gross proposal makes me optimistic.
- dist-epoch 3y ago
  > However, this commitment from Meta, One core dev for 3 years. Hardly earth-shattering, if compared to the billions poured into JavaScript.
  - manfre 3y ago
    > three engineer-years (from engineers experienced working in CPython internals) between the acceptance of PEP 703 and the end of 2025 This means multiple devs over a period of less than 3 years.
  - BiteCode_dev 3y ago
    True, but it's way better than what we had before.
- ignoramous 3y ago
  > PEP-703: Concurrent collection requires write barriers (or read barriers). The author is not aware of a way to add write barriers to CPython without substantially breaking the C-API. Jesus. Imagine a language runtime being this hamstrung.
  - BiteCode_dev 3y ago
    Well, CPython is 4 years older than Java. That's very old. When it came out, this was in store: https://img.redbull.com/images/w_3000/q_auto,f_auto/redbullcom/2016/01/06/1331768922880_2/game-boy-nintendo-console-portable-jeux-video https://img.redbull.com/images/w_3000/q_auto,f_auto/redbullc... What was not in store were: - multi-core CPU - wide spread internet access So people solve concurrency with a simple but efficient and sufficient method at the time: the GIL. And nobody planned for the scientific and ML stack.
qaq 3y ago
Hopefully Mojo makes good progress offering a good alternative
mihaic 3y ago
Over time I've changed my mind regarding the GIL. Now I think it's existence actually is a good thing, since it makes a lot of things easy and robust by default. The subinterpreters route sounds really promising since it strikes a good balance between allowing those that need same-process parallelization to be able to do so and keeping the status quo (like workers in Javascript). I'd actually veto PEP 703 at this point, since the Python optimization team is making good progress, and this could actually take them back a bit, while diverting too much energy into a low-reward avenue.
bjornasm 3y ago
In the big picture three engineer years are nothing. I bet Meta has spent 30 engineer years on no-poke Facebook.
icco 3y ago
Just rewrite all of your Python in Go. Python in 2023 is a mistake.
- throwaway5959 3y ago
  Everyone agrees except the “architect”. How do you convince him?
znpy 3y ago
to be honest... we already saw that the migration from python2 to python3 was a complete shitshow, but the value python brings is so great the ecosystem survived. i would gladly accept a python3 to python4 breaking change where all the necessary bits are changed to get real multi-threading (no-gil, gilectomy or whatever). it's just so worth it.
bfung 3y ago
Python 5000, why not.
reserved45 3y ago
[dead]
exabrial 3y ago
I just get a bad feeling about this "gift"
anacrolix 3y ago
10 years late. I remember being criticized for avoiding the GIL in some CPython C code in 2012 and I think I stopped contributing to CPython after that. There are (or were back then), curmudgeons trying to hang on to their "safe layer over 90s style C process" Python. This is a great step forward.
- rmahrt 3y ago
  Well, enjoy the 2020s style machine learning Python, where applications are already full of threading bugs even before this PEP.
developsocks 3y ago
[dead]
maiden12 3y ago
[dead]
maiden12 3y ago
[dead]
shieldused 3y ago
[dead]
shieldused 3y ago
[dead]
colgatefamily 3y ago
[dead]
colgatefamily 3y ago
[dead]
blaze43 3y ago
[dead]
blaze43 3y ago
[dead]
scarfoperator 3y ago
[dead]
scarfoperator 3y ago
[dead]
calmgarnish 3y ago
[dead]
calmgarnish 3y ago
[dead]
commercialdrop 3y ago
[dead]
commercialdrop 3y ago
[dead]
addressaboard 3y ago
[dead]
addressaboard 3y ago
[dead]
depositnature 3y ago
[dead]
depositnature 3y ago
[dead]
equallyvillager 3y ago
[dead]
equallyvillager 3y ago
[dead]
eyebrow43 3y ago
[dead]
eyebrow43 3y ago
[dead]
dowdy432 3y ago
[dead]
dowdy432 3y ago
[dead]
nonstop43 3y ago
[dead]
nonstop43 3y ago
[dead]
hooligan11 3y ago
[dead]
hooligan11 3y ago
[dead]
greensicky 3y ago
[dead]
greensicky 3y ago
[dead]
enterwee 3y ago
[dead]
enterwee 3y ago
[dead]
fireworkssnort 3y ago
[dead]
fireworkssnort 3y ago
[dead]
reeveplains 3y ago
[dead]
reeveplains 3y ago
[dead]
discovery13 3y ago
[dead]
discovery13 3y ago
[dead]
programversus 3y ago
[dead]
programversus 3y ago
[dead]
givenboard 3y ago
[dead]
givenboard 3y ago
[dead]
creative23 3y ago
[dead]
creative23 3y ago
[dead]
cynicalscoot 3y ago
[dead]
cynicalscoot 3y ago
[dead]
volcanic56 3y ago
[dead]
volcanic56 3y ago
[dead]
placidtactful 3y ago
[dead]
placidtactful 3y ago
[dead]
grinfunction 3y ago
[dead]
grinfunction 3y ago
[dead]
alongline 3y ago
[dead]
alongline 3y ago
[dead]
analysis32 3y ago
[dead]
analysis32 3y ago
[dead]
decade36 3y ago
[dead]
decade36 3y ago
[dead]
recovery54 3y ago
[dead]
recovery54 3y ago
[dead]
lilytubby 3y ago
[dead]
lilytubby 3y ago
[dead]
leechcrowded 3y ago
[dead]
leechcrowded 3y ago
[dead]
cavernousstart 3y ago
[dead]
cavernousstart 3y ago
[dead]
dispenser43 3y ago
[dead]
dispenser43 3y ago
[dead]
tailluxurious 3y ago
[dead]
tailluxurious 3y ago
[dead]
reserved45 3y ago
[dead]
tactless23 3y ago
[dead]
tactless23 3y ago
[dead]
foottermite 3y ago
[dead]
foottermite 3y ago
[dead]
siemensutility 3y ago
[dead]
siemensutility 3y ago
[dead]
skulltoy 3y ago
[dead]
skulltoy 3y ago
[dead]
poopcyan 3y ago
[dead]
poopcyan 3y ago
[dead]
screeching6 3y ago
[dead]
screeching6 3y ago
[dead]
supercargo5 3y ago
[dead]
supercargo5 3y ago
[dead]
accidental4 3y ago
[dead]
accidental4 3y ago
[dead]
boringspotted 3y ago
[dead]
boringspotted 3y ago
[dead]
alludewillow 3y ago
[dead]
alludewillow 3y ago
[dead]
snoreburnet 3y ago
[dead]
snoreburnet 3y ago
[dead]
multiply3 3y ago
[dead]
multiply3 3y ago
[dead]
bisonsurmise 3y ago
[dead]
bisonsurmise 3y ago
[dead]
sparkles87 3y ago
[dead]
sparkles87 3y ago
[dead]
peppercat 3y ago
[dead]
peppercat 3y ago
[dead]
canarycoffle 3y ago
[dead]
canarycoffle 3y ago
[dead]
limbicseed 3y ago
[dead]
effective32 3y ago
[dead]
effective32 3y ago
[dead]
stability54 3y ago
[dead]
stability54 3y ago
[dead]
squatdrunk 3y ago
[dead]
squatdrunk 3y ago
[dead]
knockicicle 3y ago
[dead]
knockicicle 3y ago
[dead]
righteous12 3y ago
[dead]
righteous12 3y ago
[dead]
chainglide 3y ago
[dead]
chainglide 3y ago
[dead]
luffrightful 3y ago
[dead]
luffrightful 3y ago
[dead]
macaw5 3y ago
[dead]
macaw5 3y ago
[dead]
limbicseed 3y ago
[dead]
pollfamily 3y ago
[dead]
pollfamily 3y ago
[dead]
enraged34 3y ago
[dead]
enraged34 3y ago
[dead]
themsink 3y ago
[dead]
themsink 3y ago
[dead]
bonuslute 3y ago
[dead]
oddsdecimal 3y ago
[dead]
oddsdecimal 3y ago
[dead]
repairleotard 3y ago
[dead]
repairleotard 3y ago
[dead]
partridgescold 3y ago
[dead]
partridgescold 3y ago
[dead]
developsocks 3y ago
[dead]
boundary5 3y ago
[dead]
boundary5 3y ago
[dead]
complete53 3y ago
[dead]
complete53 3y ago
[dead]
manageapt 3y ago
[dead]
manageapt 3y ago
[dead]
generateturn 3y ago
[dead]
generateturn 3y ago
[dead]
offensive53 3y ago
[dead]
offensive53 3y ago
[dead]
jocularsesame 3y ago
[dead]
jocularsesame 3y ago
[dead]
frameworkher 3y ago
[dead]
frameworkher 3y ago
[dead]
crackmischief 3y ago
[dead]
crackmischief 3y ago
[dead]
garagehurried 3y ago
[dead]
garagehurried 3y ago
[dead]
olympicswoop 3y ago
[dead]
olympicswoop 3y ago
[dead]
strategyrufous 3y ago
[dead]
strategyrufous 3y ago
[dead]
disturbed43 3y ago
[dead]
disturbed43 3y ago
[dead]
dolphin21 3y ago
[dead]
dolphin21 3y ago
[dead]
scope54 3y ago
[dead]
public23 3y ago
[dead]
public23 3y ago
[dead]
ripladder 3y ago
[dead]
ripladder 3y ago
[dead]
obsidianrat 3y ago
[dead]
obsidianrat 3y ago
[dead]
typicalgeneral 3y ago
[dead]
typicalgeneral 3y ago
[dead]
exceedplum 3y ago
[dead]
exceedplum 3y ago
[dead]
drawers43 3y ago
[dead]
dinner324 3y ago
[dead]
dinner324 3y ago
[dead]
ogleturmeric 3y ago
[dead]
ogleturmeric 3y ago
[dead]
imaginary34 3y ago
[dead]
imaginary34 3y ago
[dead]
undertremble 3y ago
[dead]
undertremble 3y ago
[dead]
huskyarab 3y ago
[dead]
huskyarab 3y ago
[dead]
finance43 3y ago
[dead]
finance43 3y ago
[dead]
imperfect42 3y ago
[dead]
imperfect42 3y ago
[dead]
drawers43 3y ago
[dead]
cluttered34 3y ago
[dead]
cluttered34 3y ago
[dead]
skilletsun 3y ago
[dead]
skilletsun 3y ago
[dead]
rinkwet 3y ago
[dead]
rinkwet 3y ago
[dead]
bloody34 3y ago
[dead]
bloody34 3y ago
[dead]
vietvu 3y ago
After many years. GIL is fine to me, it is not a problem at all.
writefish 3y ago
[dead]
writefish 3y ago
[dead]

656 points by bratao 3y ago

scope54 3y ago

[dead]

stanislavb 3y ago

[flagged]

noSyncCloud 3y ago
Well, "put your money where your mouth is" would be more apposite. I commend them for volunteering to contribute in this way. A rising tide and all that.
dcchambers 3y ago
Isn't this just how most open source software with enterprise customers operate? Big companies pay (money or with developer time) in order to gain support and to steer the product to add features they want. The open source produce lives on, developers get paid for their work, big co gets features they want, and everyone lives a happy life.
kzrdude 3y ago
Microsoft is currently having a multiple person team work on the faster cpython project. That's "money talking" in the same sense.

kzrdude 3y ago

I believe you want to link to https://discuss.python.org/t/a-fast-free-threading-python/27903/99 https://discuss.python.org/t/a-fast-free-threading-python/27... (comment #99, the most recent right now.)

jsnell 3y ago

The editorialized title "Meta pledges Three-Year sponsorship for Python if GIL removal is accepted" seems misleading at best. The actual wording was: > support in the form of three engineer-years [...] between the acceptance of PEP 703 and the end of 2025 It seems much more like them pledging engineer time from Meta employees to work on this project than sponsorship, not a monetary sponsorship like the title implies.

o1y32 3y ago
Yep, the original comment was very carefully worded.
meitros 3y ago
And also in direct response to a comment from GvR, not something out of the blue
- derbOac 3y ago
  Yes, and the comment is to request help essentially: "it would be great if Meta or another tech company could spare some engineers with established CPython internals experience to help the core dev team with this work."
deleted 3y ago
[deleted]
hn_20591249 3y ago
Offering dedicated specific CPython resources (aka. enginneering hours) is worth more than a monetary sponsorship in my view.
- xcdzvyn 3y ago
  Right, but that's not the topic at hand. For better or for worse the title is a little misleading.
- smeyer 3y ago
  That also depends on the scale of the monetary sponsorship, though. If I heard something like "Meta/Google/Whoever is the main sponsor of Python for the next 3 years", I'd assume (perhaps incorrectly) much more money per year than it takes to hire a single engineer. On the other hand, someone just saying "sure, we'll do the silver tier at your next few conferences" is worth a whole lot less than one engineer. Regardless, the previous commenter's point stands that the title could be a lot more informative.
- 3y ago

gautamcgoel 3y ago

This is potentially problematic. It creates a conflict of interest: will the GIL proposal be accepted based on technical merits and potential benefits to the Python community overall, or just because the Python foundation wanted money? The problems that Meta faces in production are not necessarily the problems faced by every Python developer. In particular, Meta might value performance more than backwards-compatibility, while other Python users might feel differently. If Meta were to offer unconditional support, that would clearly be good for Python; attaching conditions to their support makes the situation trickier to navigate.

draw_down 3y ago
[dead]
jsnell 3y ago
Your premise is incorrect, as this is not a promise of money.
bob1029 3y ago
What is Meta's end game with Python? Do they genuinely just want a stable build without GIL because of some cranky in-house code piles, or is this the first step towards a bigger mission to wrangle an entire ecosystem?
- AlphaSite 3y ago
  They use Python as the basis for instagram, which is a large growing service.
  - bugglebeetle 3y ago
    And now Threads as well.
- trollied 3y ago
  Would you they rather used these man years to implement it behind closed doors & never release the build? They use Python. They want to donate engineering time. They think this is a good idea. Why does there have to be a sinister motive?

a1o 3y ago

It's three engineer years until 2025, and it's just a person mentioning on the discuss board. It sounds a bit weird to throw something like this in a public forum.

jsmeaton 3y ago
Why weird? The request was made there. The discussion on the PEP is there. And the person answering is a core Python dev and part of the Python team at meta/insta. Their team wants it, and is offering hours to help get it done. Is this not what everyone wants from businesses using OSS?
SoftTalker 3y ago
So they'll put 36 people on it for a month in November 2024?

andrewclunn 3y ago

Evil response. Say, "Sure!" and release python v4 with their feature request, and watch the python split wars happen all over again >:-}

jowea 3y ago
I genuinely wonder if this issue would cause a fork. At least a long term maintenance that keeps the GIL.
- kzrdude 3y ago
  Python is closer to C than we all like to imagine, in more than one way. Lots of access to low-level libraries. Long history of writing modules in C. And little in actual memory safety protection more than relying on programmers to please not write bugs in their C or ctypes code. Philosophically, Python is close to C in the sense that low-abstraction interfaces to system functionality (file descriptors, memory) exist. Numpy allows access to uninitalized memory and you can manipulate how numpy uses memory (mmap, shared memory, sharing memory between objects). Ctypes allows access to malloc and dereferencing dangling pointers. This is not exactly normal Python, but it's inside the realm of the possible in Python. All of this makes me worried that the challenge of "free threading" is quite large. I wonder if the subinterpreters solution offers a safer route. At least it's not pulling off the GIL band-aid all in one go.
  - formerly_proven 3y ago
    Can’t even call print or logging from signal handlers (that’s UB in Python), despite being bounced off of the VM.
  - kzrdude 3y ago
    On other hand, allowing access to free threading would be a straight-line continuation of this culture: just make that feature available. ("we're writing system code in a high level language.")

brunes 3y ago

They committed three person-years, not three years. This project would need dozens of person-years over a three year period. Also a comment on Github is not a binding support contract. Meta executives could deprioritize this project at any time... hell the person making the commitment could already be laid off, we have no clue. As someone who worked in big tech for a long time, trust me - it needs to be in writing with an exec signature.

Agingcoder 3y ago

It’s an interesting debate ( money aside ). In the past 15 years, at least to my eyes, one of the most important changes in soft eng culture has been the now systematic search for correctness. Systematic, organized, large scale Testing is one side of the coin, but the real value , and significantly more important change to me is guarantees/proofs : static analysis, stronger type systems, etc. So type annotations in Python, typescript, rust instead of c++, etc. Tools as well : golang race detector, infer, coverity, pvs studio, code peer (Ada)/spark, compcert, etc. In this particular case, I understand that removing the Gil would create potential new risks ( but provide better performance) and although tooling is mentioned, it’s not officially part of the plan, so it feels like a regression of some sorts.

klysm 3y ago
It might be worth it though because somehow python had ended up being the lingua Franca in a many applications where performance matters a great deal (ML, scientific applications, etc). I don’t think the performance benefits for something deployed at such a large scale should be understated.
- local_crmdgeon 3y ago
  Indeed and to add - the environmental impact of Python’s speed is nontrivial and growing
  - klysm 3y ago
    Although you are almost certainly correct, I’m curious if there is a case where faster doesn’t mean more power efficient I.e. more concurrency but more power overall
    - H8crilA 3y ago
      Concurrent execution is ~always less power efficient than serial execution. I have no idea what the parent comments are talking about. For almost any work X with time to run on a single core T it will run on two cores in time larger than T/2, and on three cores in time larger than T/3, ... This is due to synchronization overhead (e.g. networking, locks, delays) and also often due to shared resources getting saturated (e.g. VRAM on a GPU). That is unless in the serial execution you still have to pay for some resources that are unutilized.

synergy20 3y ago

So generous! The FAANG etc failed me for anything open source sponsorship related. Their business depends on it, they made a fortune out of it, yet they donate little or nothing to it, or worse, they forked it and was reluctant to upstream anything. pick Amazon randomly, it went from exploiting to rip-off in my opinion, thanks to its boss , who sails on a luxury yacht and asks all his employees to be frugal. they all look similar to me as far as supporting OSS goes.

nradov 3y ago
Meta contributes a huge amount to the open source community. https://opensource.fb.com/ https://opensource.fb.com/
- stevefan1999 3y ago
  React alone is one of the biggest feast Meta brought to open source community, and shaped the web from monolithic pages (back then PHP and jQuery is the majority) towards modular components design. Later they even introduced functional programming paradigm in the mix. Next.js exists too which mashed up PHP/Ruby style with React.
acedTrex 3y ago
In terms of companies that rip off open source and do not give back meta is certainly one of the more active "give back" companies. React/Native, docusaurus, buck, pytorch, rocksdb...
- synergy20 3y ago
  yes some big companies did open source projects and Meta is a good role model, for many those OSS projects, they work for the companies themselves first then the community, though they are indeed still 1 million times better than closed and proprietary code. I'm mainly referring to long standing fundamental projects that made the rest projects possible, not those projects that are created and managed by the big companies themselves.

dig1 3y ago

Whatever happens, I'm hoping we won't see another 2to3-like migration. I moved from Python a long time ago due to its multi-threaded limitations (among other things) to Java and JVM, and I really appreciate the stability the JVM team tries to maintain. Things are not perfect, but I'd take stability/compatibility over perfection any day.

whoknowswhat11 3y ago
Could not agree more. The purposeful unnecessary breaking stuff was maddening- and then being lectured at like you were an idiot more so. No more u”” for you!
- atdt 3y ago
  There is zero chance of that happening. Guido van Rossum (and other key figures in the Python community) have spoken very candidly for years about the mistakes they made in the 2-to-3 migration and their decisions in the year since have demonstrated their commitment to not repeating these mistakes.
  - blamazon 3y ago
    I was curious about these comments and did a small web search. I found a video interview from May 21, 2021 [1] and have pasted some excerpted quotations from it from Guido van Rossum below for others who are curious. “Python 4, at this point whenever it’s mentioned in the core development team, it is very much as a joke… We’ve learned our lesson from Python 3 vs 2, and so it’s almost taboo to talk about a Python 4 in a serious sense.” [...] “I normally talk about that as a mistake, because Python was more successful than the core developers realised and so we should have been much more aware and supportive of transitioning from Python 2 to Python 3” [...] “I’m not thrilled about the idea of Python 4 and nobody in the core dev team really is – so probably there never will be a 4.0 and we’ll just keep numbering until 3.33, at least” [...] “We now have a strict annual release schedule, so after 3.10 will be 3.11 and after that will be 3.12, and so forth. We can go up to 3.99 before we have to add another digit. Adding another digit is not completely trivial, but still much better than going from 3 to 4." [1]: https://www.youtube.com/live/aYbNh3NS7jA https://www.youtube.com/live/aYbNh3NS7jA

oneTbrain23 3y ago

I think at this point it is better Meta to ditch python and invest in a new programming language that mimics exactly wording for wording of python but without GIL. Google did it with their Carbon for C++, Go for C/D/C++. Microsoft even wrestle with Java for .NET and at one point their J++ 2 decades ago. Meta shpuld create their own. Maybe dump their resources into Modular. Python at this point is basically a C++ with a hotch potch of features and codebase. Start from clean like Mozilla Rust would help entire programming a lot than invest in a niche subset feature of Python which they dont have any control at all (I am speaking from corporate point of view). Python is like Perl, it will continue to have its place even decades later to be generic or niche for AI. But the rest of us may be moving on to something more specialized and cleaner like Rust, Ruby, Modular, etc.

mlrland 3y ago
Agreed, they should port their AI stacks to a functional language. It looks like these efforts are designed to prop up Python for the scientific stack.
moonchrome 3y ago
migrating from python to Ruby for something cleaner ?!
- T-A 3y ago
  From the top post in that thread: Most of this work has been on Javascript, which is single-threaded and less mutable than Python, but PyPy has also made some significant contributions. PyPy has a GIL. There is also work on Ruby. Ruby is even more mutable than Python, but also has a GIL. Work on Ruby mirrors that on Javascript.
  - dragonwriter 3y ago
    Ruby's GVL is no longer truly global because of Ractors, which are a different approach to reducing the impact of a global lock.
3y ago

mlrland 3y ago

[flagged]

elaus 3y ago

The title is highly editorialized and links to a comment that has nothing to do with the sponsorship. Direct link to the comment, where Meta offers to commit to working on this issue for 3 person-years: https://discuss.python.org/t/a-fast-free-threading-python/27903/99 https://discuss.python.org/t/a-fast-free-threading-python/27...

pixelgeek 3y ago

I am curious how much of the python community the GIL affects? And is Facebook's interest related to AI performance?

qbasic_forever 3y ago
Almost every single data structure access in python, even reading a dictionary item, at some level depends on the GIL for true correctness right now. It is very deeply embedded in cpython.
- pixelgeek 3y ago
  I didn't phrase that well. How much of the Python community is writing code that would be positively affected by the removal of the GIL? The entire debate seems to be for code that strikes me as being far and away from the typical Python programmer.
  - netheril96 3y ago
    Every ML engineer will be impacted. Web server probably less so.
    - singhrac 3y ago
      I think it’s the other way around? I haven’t run into any ML code that could be multithreaded that wasn’t written in C++, but have often run into server tasks that could use a polling thread, etc. All the ML code is written in lower level languages and that’s very unlikely to change, GIL or no.
      - brrrrrm 3y ago
        driving multiple GPUs on the same node is better handled by threads. Python is forced to use multiprocessing
        3y ago

qbasic_forever 3y ago

The GIL problem won't be solved by throwing engineer hours at it (not even Meta engineers). Fundamentally every single piece of python code ever written will have to stop and now worry about potential race conditions with innocent things like accessing a dictionary item or incrementing a value. It's a massive education and legacy code problem at least on the same scale as the python 2 to 3 migration. I honestly don't think the community is ready for this change and don't expect to ever see stock cpython drop the GIL--perhaps there will be a flag to selectively operate a python process without the GIL (and leave the onous on you to completely test and validate your code works with potentially new and spooky behaviour).

wuiheerfoj 3y ago
Is this not exactly what the PEP-703 is?
mountainreason 3y ago
I dont get this. Just because you don't have the GIL doesnt mean that your previously single threaded code is now multithreaded and stepping on itself.
- 411111111111111 3y ago
  From previous discussions it's my understanding the c integration is going to be the cause for the issues. From a python perspective it wouldn't necessarily be a big change, but everything can branch out to c, and there you're going to get in trouble with shared memory.
  - dwaite 3y ago
    The most significant impact of this change is that python threads can run at the same time. Before, calls to C API were essentially cooperative multithreading yield points - even if you have 100 python threads, they can't run concurrently under the GIL. 99 are blocked waiting on the GIL. C extensions have always been able to use real threading. But now there is no GIL to synchronize with the python interpreter on ingress/egress from the extension.

Aachen 3y ago

[flagged]

aardvarkr 3y ago
The GIL is Python’s global interpreter lock which bottlenecks performance in multithreaded applications by locking variables. They’re working on removing it but it introduces race conditions if programmers aren’t aware of the change.
londons_explore 3y ago
The code is here: https://github.com/discourse/discourse https://github.com/discourse/discourse I'm sure they'd welcome a patch to fix the forums.
zdragnar 3y ago
Do you have JavaScript disabled? It is a deep link into a very, very long forum thread. Instead of pagination, comments outside of a certain window are loaded as you scroll. https://discuss.python.org/t/a-fast-free-threading-python/27903 https://discuss.python.org/t/a-fast-free-threading-python/27... Should take you to the first post, which is an overview of the proposal problem and potential solutions. Mobile Chrome renders the page just fine. No idea about what other WebView you're using, but JS definitely needs to be enabled to load additional content. In short, GIL is the global interpreter lock, something that is innocuous in single threaded software but a bane for performance in a true multithreading environment. I'd recommend reading up on it elsewhere if you're not familiar with it, as the post elides a lot of detail (the audience is the forum is, after all, people already familiar with python internals). "nogil", therefore, is a shorthand for CPython running without the global interpreter lock. The crux of the proposal is a discussion on how to achieve it without making large sacrifices to reliability or performance in single threaded scenarios.
- Aachen 3y ago
  JavaScript enabled. Like I said, first site that ever behaves like this; three quarters of the Internet would be broken if I didn't have JS. (And Firefox and archive.is also run JS afaik) > No idea about what other WebView you're using, Android default, so also chrome-like, just not the proprietary Google Chrome browser > "nogil", therefore, is a shorthand for CPython running without the global interpreter lock. Ooh, I should have realised what nogil means. If this had been in the headline with capitalisation like noGIL, I wouldn't even have needed to click to understand what it is Facebook wants to work on. Thanks!

punnerud 3y ago

PEP 703 will add the option to disable GIL (default is on). More context here: https://peps.python.org/pep-0703/ https://peps.python.org/pep-0703/

simonw 3y ago
That PEP had not yet been formally accepted. That's what this thread is about.

sheeshkebab 3y ago

20+ years later, and billions of lines or python code later, the GIL discussion is still there. Kind of an amazing mess of a problem… mainly shows the priority of python being a ducktape type solution from the start.

mkl95 3y ago

Don't Meta maintain their own fork?

tekknolagi 3y ago
I previously worked on Cinder. Maintaining a fork is hard and the goal is not to do that.

bjourne 3y ago

Latest decade in software engineering indicate that multi-processing is much preferable over multi-threading. It's the architecture Edge, Firefox, and Chrome uses. So the question is what use cases multi-threading address that are not already covered by multi-processing? The memory overhead that multiple processes cause is relatively insignificant on recent machines with 32GB+ of ram.

SR2Z 3y ago
Tons of use cases! There are lots of concurrent algorithms that use locking and shared memory instead of message-passing. Matrix multiplication or tree search come to mind.
- bjourne 3y ago
  Parallel blocked n^3 matrix multiplication doesn't use any synchronization primitives (short of join). The processes read from the same input matrices, but write to non-overlapping regions of memory. This is easily accomplished using posix shared memory. Indeed, this is how it is done when the matrices to be multiplied are too large to be handled by single worker nodes.
jvanderbot 3y ago
I don't think anyone is unilaterally going to move to multiprocess as a programming paradigm. Web browsers have their own reasons for using Multi-process, including security from memory isolation, resilience against crashes in the client side code, killing individual tabs, and so on. I'd wager the vast majority of programs being written that need concurrency or parallelism still use multi threading or SIMD.
- kuchenbecker 3y ago
  This must be browser specific, as servers still use threading. The 32GB mentioned is very small as well, we run up to 1.5TB nodes.
  - 3y ago

Kwpolska 3y ago

> If PEP 703 is accepted, Meta can commit to support […] between the acceptance of PEP 703 and the end of 2025 Meanwhile, the Steering Council is dragging their feet, even though so many people in the community have chimed in their support for nogil being a thing (in the linked thread and two others). https://github.com/python/steering-council/issues/188#issuecomment-1575106739 https://github.com/python/steering-council/issues/188#issuec...

lagt_t 3y ago
This is a decision with huge ramifications and the PEP was submitted only 5 months ago. Caution is welcomed here. Specially with PEP 684 around the corner.
- Kwpolska 3y ago
  As @colesbury said in the GitHub thread: > The PEP was posted five months ago, and it has been 20 months since an end-to-end working implementation (that works with a large number of extensions) was discussed on python-dev. I would expect the SC to be active participants in the community, including the python-dev mailing list, so they should have known what this change means by that point.

gexaha 3y ago

Sorry, stupid question, can someone tell, please, how do other interpreted languages deal with problem similar to GIL or noGIL?

ddtaylor 3y ago
I think comparing it to something like nodejs the way they work around the issue is that almost all their code is written in JavaScript itself. Python has a different model where a very large amount of the code is written in c and python itself is just a glue.
- rcme 3y ago
  A huge amount of NodeJS is written in native code. JS is single threaded. Async work doesn’t work without native code. JS doesn’t need a GIL because it only has one thread.
aardvark179 3y ago
You use smaller scale locks as and when you need them, and you spend a lot of time to carefully implement core threading constructs and similar to make sure they are correct. Most of the time in an interpreter you’re iterating through the byte code for a function, and mutating variables. It doesn’t matter if two threads are executing that same byte code, it only matters if they are mutating the same object. That’s not to say there aren’t some operations that need coordination across all threads. For that you implement safe points so you signal that something has to be done, wait for all threads to reach a safe point, do the work, and then release the threads again. You can often be even smarter about this and avoid stopping all threads at once but instead stagger things. Allocation and GC you can make more thread local to avoid stopping the world too often.
csmpltn 3y ago
The GIL is a conscious trade-off between contention/performance against a simpler code. Without the GIL, you'd still need to use different locking/synchronization mechanisms to ensure thread safety (if required), but they'd be more nuanced and spread over the entire codebase (complicating the backend).

runevault 3y ago

I can't even imagine how many engineering years it would require to fix just the most used libraries that expect the gil to exist. I assume 3 years wouldn't even cover the actually interpreter, throw in the library piece and how is this useful?

singhrac 3y ago
I can’t imagine you’ve read the proposal with a comment like this. The interpreter is already patched (twice in the proposal, for two different versions of Python), and Sam Gross has personally already patched many commonly used Python libraries. Here’s numpy patched, a mess of C and Fortran written for high performance code: https://github.com/colesbury/numpy/commits/v1.24.0-nogil https://github.com/colesbury/numpy/commits/v1.24.0-nogil This comment is the definition of FUD.

santiagobasulto 3y ago

There's a great talk by David Beazley (I don't remember which one) that he basically explains that removing the GIL isn't difficult at all. After all, it's just one lock. The issue is all the libraries and packages that were built around it. It's now been YEARS of building on top of the GIL. So anyways, PEP 703 is a a nice effort, but I doubt we (everyday mortals) can enjoy it. Meta, and big companies with a specialized team might be able to exploit it by making sure their entire stack is GIL-free. EDIT: My bad, the talk is from Larry Hastings: https://www.youtube.com/watch?v=P3AyI_u66Bw https://www.youtube.com/watch?v=P3AyI_u66Bw

kzrdude 3y ago
Sam Gross has worked vs numpy and other modules to make it work well in practice
thelastbender12 3y ago
> So anyways, PEP 703 is a a nice effort, but I doubt we (everyday mortals) can enjoy it. I'd suggest we can be more optimistic. There is a lot of python, regular users write daily, where we delegate orchestration to established libraries - asyncio/web-frameworks/pytorch. The GIL limits how much they can parallelize your code, and its removal will help with that.
tomwojcik 3y ago
2016. A lot has changed since then and AFAIK numpy and other most popular libs with bindings in C have an experimental branch that is already nogil compatible. Not saying he isn't wrong, though.
klysm 3y ago
“Just one lock” is kind of misleading if decades of software has accumulated that is predicated on its existence
gjulianm 3y ago
> Meta, and big companies with a specialized team might be able to exploit it by making sure their entire stack is GIL-free. Not really. Most of the popular libraries will have nogil versions ready for sure (numpy, pandas, pytorch, etc). Server applications will probably benefit from being able to serve multiple requests in a real multithreaded environment without many changes (in fact, I bet a lot of HTTP libraries will see simplifications due to not needing to deal with processes for real parallelism). Even packages without changes will probably have at least a small degree of thread safety (for example, two instances of the same object should be independent and could be used in different threads) that allows users to still leverage parallelism.

meindnoch 3y ago

[flagged]

js2 3y ago

Removing the GIL will not break the vast majority of existing Python code. Here's the backwards compatibility section of PEP 703: https://peps.python.org/pep-0703/#backwards-compatibility https://peps.python.org/pep-0703/#backwards-compatibility That section is short and I encourage you to read it in full. Here's what it says about how removing the GIL affects existing Python code: • Destructors and weak reference callbacks for code objects and top-level function objects are delayed until the next cyclic garbage collection due to the use of deferred reference counting. • Destructors for some objects accessed by multiple threads may be delayed slightly due to biased reference counting. This is rare: most objects, even those accessed by multiple threads, are destroyed immediately as soon as their reference counts are zero. Two places in the Python standard library tests required gc.collect() calls to continue to pass. That's it with respect to Python code. Removing the GIL will require a new ABI, so existing C-API extensions will minimally need to be rebuilt and may also require other changes. Updating C-API extensions is where the majority of work will be if the PEP is accepted. This will be an opt-in feature by building the interpreter using `--disable-gil`. The PEP is currently targeted at Python 3.13. This is nothing like the Python 2 > 3 transition.

Waterluvian 3y ago
which python which python3 which python3nogil
- echelon 3y ago
  venv, virtualenv, pipenv, pyvenv, venvwrapper, conda, ... Python4 needs a hard reset.
  - whalesalad 3y ago
    those are all means to the same end. venv == virtualenv virtualenvwrapper is ancient not rly used anymore pyenv is a third party tool that makes some of this easier, notably around creating more than just a virtual env in that you also choose the Python version. Python is not hard to deal with in this regard I think people are just uninformed.

_a_a_a_ 3y ago

> Fundamentally every single piece of python code ever written will have to stop and now worry about potential race conditions Except for every single piece of python I have ever written which will continue to work just fine.

deleted 3y ago

[deleted]

TheRealPomax 3y ago

As someone not particularly tuned into the Python ecosystem, what is "nogil", though?

mehdix 3y ago
no GIL (Global Interpreter Lock)
- TheRealPomax 3y ago
  That covers the "no" part, what's a global interpreter lock?
  - charcircuit 3y ago
    It is a global lock that is required to run the interpreter
    - TheRealPomax 3y ago
      Cheers. That does sound like it would impair actually being useful on multicore, multithreading cpus (which of course has been all of them for basically the last two decades)
foundart 3y ago
no Global Interpreter Lock
- foundart 3y ago
  Its presence makes it difficult for python to run multi-threaded.

nocman 3y ago

Might be worth changing the title to "no-GIL". My first thought was "What is nogil CPython?" - thinking it was some specialized fork of CPython. I guess you could say that is technically true. I was previously aware of the GIL in Python, yet it still didn't occur to me immediately.

kkirsche 3y ago

Seeing so many comments about how hard it is to just break compatibility and upgrade is sad. Instead of just throwing our hands up and saying it’s too hard, we could adopt the model the JavaScript ecosystem has seen more of which is codemods that upgrade the code for us. If as a community we invest in those tools and make them easier to build, the cost of upgrading goes down and the velocity of high-impact changes can increase.

inglor 3y ago
TC39 has a famous "don't break the internet" mantra. Even the leeway that Python has with deprecations/features JavaScript doesn't. It's versionless, code automatically gets updated to whatever the browser is using. JavaScript evolves quickly but so does Python! (Note that your approach is exactly what they said in the 2 to 3 transiton btw with a special tool that didn't work too well)
- kkirsche 3y ago
  That’s not what that library was in my opinion, it was a compatibility layer not a rewriting tool which is what I referenced. Having a layer in between simply prolongs the issue and creates many types of problems based on adoption or not. On the other hand, when rewriting you can apply that either as an author or as an end user depending on the quality which meaningfully allows for different results.
VWWHFSfQ 3y ago
I'm not sure what "codemods" means. Just static analysis code changer? Python is so highly runtime dynamic I'm not sure a tool is even possible to upgrade behavior, preserving correctness and intent (bugs and all).
- twosdai 3y ago
  Not the poster of the question, But I think they're referencing the litany of transpilers and repackagers which exist for js. So you can add new features and then still have it run on really old systems like internet explorer 9 if you need to. This has problems obviously and in my opinion for python it would be preferable. My reasoning being that if you need your code to work on an older system being able to write and use current syntax is preferable to not, and the hard bifurcation that python did with 2 to 3 and now potentially with 3 to nogil seems to me just to break apart the ecosystem more.

resonious 3y ago

It's crazy how much work we put into trying to speed up these scripting languages. It's the same with Ruby. Shopify spends tons of dev resources on making JIT and stuff.

pkkm 3y ago
What do you find so crazy about it? Dynamically typed languages like these can be fast. It has already been demonstrated with Common Lisp and, more recently, JavaScript. Not only that, but LuaJIT has shown that you don't need impossibly complicated techniques or man-decades of effort to get very good performance. In Python's case, the main obstacle to improving the implementation isn't any feature of the language itself, but the giant ball and chain that is the C API.

hgs3 3y ago

PEP 703 mentions the multiprocessing module which I used recently with great success. It is essentially message passing parallelism, i.e. the actor model. I would think even with the GIL removed message passing is still the best approach for a higher-level language, like Python, to handle parallelism as it is conceptually simple and lock free. The primary disadvantage of the multiprocessing module is it uses separate processes which means my resource heavy Python extension needs to be duplicated multiple times in memory (at least on Windows). I think the move to supporting threads means the module could leverage them instead of separate processes, avoiding the need to duplicate C extensions in memory, and thereby reducing the overall memory pressure on a system.

packetlost 3y ago
I agree that message passing can be a really good choice. The problem is the overhead of passing large messages can be really substantial. In general, you'll need to store messages in memory 4x per message (at least temporarily): once on each end for the Python representation and the serialized "on the wire" representation. There's also the issue with `pickle` generally being a horrible serialization format and being the default. There are ways around this, Python has a rather rudimentary and archaic shared memory subsystem[0] that can make this much more efficient. On the other hand, the Python multiproccessing sync primitives actually work over a network with almost no code changes, so you can horizontally scale with little effort... but then you're paying the serialization and network overhead, so ymmv. [0]: https://docs.python.org/3/library/multiprocessing.shared_memory.html https://docs.python.org/3/library/multiprocessing.shared_mem...
shepardrtc 3y ago
Multiprocessing is great. Very easy to use and with the Manager(), passing data is easy enough, though very "slow" relatively speaking. It has to serialize the data, send it to the Manager process, then send to all the processes (I believe), and then deserialize it. Perhaps this nogil update can speed that up?
tga_d 3y ago
I have no experience with Windows, but at least on Linux, if the forking is handled intelligently (namely, late enough that identical assets don't need to be re-written), duplicated memory should be handled by Copy on Write.

sanket1729 3y ago

Just to clarify, this is three engineer years. Meaning a cumulative of 3 years over all engineers. I fail to see why this is a big deal. Don't big tech companies contribute much more to python FOSS

Animats 3y ago

Why waste effort on speeding up the old CPython interpreter rather than working on PyPy, an actual compiler? [1] "On average, PyPy is 4.8 times faster than CPython 3.7" [1] https://www.pypy.org/ https://www.pypy.org/

slekker 3y ago
What is the catch with PyPy? If it was a drop-in replacement for CPython, wouldn't everyone choose it as the de-facto version of Python?
- cpburns2009 3y ago
  Some c modules are incompatible with PyPy. Two common ones are psycopg2 (PostgreSQL driver) and pyodbc (ODBC driver). There are alternatives that work but they don't have quite as many features (psycopg2cffi and pypyodbc). Ansible also runs slower in PyPy than CPython.
  - jdsalaro 3y ago
    > Ansible also runs slower in PyPy than CPython Do you know the reason?
    - cpburns2009 3y ago
      I tested this with a playbook that installs a set of scripts and dependencies on a server. In all there's ~30 tasks. It takes ~1 minute using CPython 3.10 and ~1.5 minutes using PyPy 3.10 (v7.3.12). Ansible says libyaml is installed in both runtimes so that's ruled out. I wonder if it's the difference in interpreter start-up time, and it accumulates over time as Ansible starts so many Python processes as it runs its tasks.
- aeyes 3y ago
  It's hit and miss. Sometimes I get almost no improvement and sometimes I get 10x. But the slow warmup and up to 3x memory use (in my experience) really make me prefer CPython unless I have a very specific problem.

stainablesteel 3y ago

i get that it would feel nice to have real multithreading, but if i want real multithreading with python i just use xonsh to pipe in bash insert bell curve meme

BiteCode_dev 3y ago

This is a delicate issue. As guido stated (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...): > If there’s one lesson we’ve learned from the Python 2 to 3 transition, it’s that it would have been very beneficial if Python 2 and 3 code could coexist in the same Python interpreter. We blew it that time, and it set us back by about a decade. So it's not so easy to decide to go with again 2 different versions of Python. I understand how caution they are. However, this commitment from Meta, complemented with MS financing Guido, and the quality of Sam Gross proposal makes me optimistic.

dist-epoch 3y ago
> However, this commitment from Meta, One core dev for 3 years. Hardly earth-shattering, if compared to the billions poured into JavaScript.
- manfre 3y ago
  > three engineer-years (from engineers experienced working in CPython internals) between the acceptance of PEP 703 and the end of 2025 This means multiple devs over a period of less than 3 years.
- BiteCode_dev 3y ago
  True, but it's way better than what we had before.
ignoramous 3y ago
> PEP-703: Concurrent collection requires write barriers (or read barriers). The author is not aware of a way to add write barriers to CPython without substantially breaking the C-API. Jesus. Imagine a language runtime being this hamstrung.
- BiteCode_dev 3y ago
  Well, CPython is 4 years older than Java. That's very old. When it came out, this was in store: https://img.redbull.com/images/w_3000/q_auto,f_auto/redbullcom/2016/01/06/1331768922880_2/game-boy-nintendo-console-portable-jeux-video https://img.redbull.com/images/w_3000/q_auto,f_auto/redbullc... What was not in store were: - multi-core CPU - wide spread internet access So people solve concurrency with a simple but efficient and sufficient method at the time: the GIL. And nobody planned for the scientific and ML stack.

qaq 3y ago

Hopefully Mojo makes good progress offering a good alternative

mihaic 3y ago

Over time I've changed my mind regarding the GIL. Now I think it's existence actually is a good thing, since it makes a lot of things easy and robust by default. The subinterpreters route sounds really promising since it strikes a good balance between allowing those that need same-process parallelization to be able to do so and keeping the status quo (like workers in Javascript). I'd actually veto PEP 703 at this point, since the Python optimization team is making good progress, and this could actually take them back a bit, while diverting too much energy into a low-reward avenue.

bjornasm 3y ago

In the big picture three engineer years are nothing. I bet Meta has spent 30 engineer years on no-poke Facebook.

icco 3y ago

Just rewrite all of your Python in Go. Python in 2023 is a mistake.

throwaway5959 3y ago
Everyone agrees except the “architect”. How do you convince him?

znpy 3y ago

to be honest... we already saw that the migration from python2 to python3 was a complete shitshow, but the value python brings is so great the ecosystem survived. i would gladly accept a python3 to python4 breaking change where all the necessary bits are changed to get real multi-threading (no-gil, gilectomy or whatever). it's just so worth it.

bfung 3y ago

Python 5000, why not.

reserved45 3y ago

[dead]

exabrial 3y ago

I just get a bad feeling about this "gift"

anacrolix 3y ago

10 years late. I remember being criticized for avoiding the GIL in some CPython C code in 2012 and I think I stopped contributing to CPython after that. There are (or were back then), curmudgeons trying to hang on to their "safe layer over 90s style C process" Python. This is a great step forward.