17 ms·

Python Language Summit: Python Without the GIL

304 points by bratao 4y ago

moelf 4y ago
- gjvc 4y ago
  why are you shilling julia in a thread about the python GIL?
  - moelf 4y ago
    :
    - gjvc 4y ago
      many successful projects and businesses can directly attribute their success to choosing and using python, in contrast to your unsubstantiated opinions. you are shouting into the void, and looking foolish while doing so.
    - blindseer 4y ago
      I genuinely think the Julia community should have guidelines on how to act on a public forum when advocating for Julia. I've had so many instances of being rubbed the wrong way from Julia folk. In some ways, it is as annoying as the RIIR folk, but it just happens to be a smaller number of people. I for one am excited to see the GIL-ectomy work come to the stage that it is today. I followed Larry Hasting's work back in 2016/2017, and I'm glad to see Sam has taken the mantle with Larry's blessing.
      - gjvc 4y ago
        case in point here; guy just edits his comments down to a colon and disappears without a word. the thing which makes this forgivable to me about this kind of astroturfing / shilling / etc is that the people doing it really do believe they are doing good when they are doing it and they don't believe for a moment that other people will see what they are doing for what it is.
metadat 4y ago
> “We need to lay out a plan of how to proceed,” remarked Pablo Galindo Salgado. “Just creating a PR with 20,000 lines of code changed is infeasible.” One of the saddest things about popular open-source projects like Python is how inevitably the maintainers become worn down and jaded over time, due to constantly filtering and protecting Python from dumb or nonsensical ideas. Then when something like this comes along, a true game changer, maintainers have no energy or goodwill left to collaborate on these infinitely important initiatives, like removing the dogdamn GIL. This is way more significant than everything I'm aware of that's happened since the birth of the language. All other things have been, trivial miuntiae in comparison. It bears repeating: "everything else has been trivial minutiae in comparison to a GIL-ectamy for Python." It cannot be understated, removing the GIL will be a HUGE deal for Python! It's an ugly wart which has existed for about 30 years, and nobody else has produced and delivered a working solution to the community. I wish Team Python would welcome GIL Eradication with open arms and a supportive attitude. This would look like focusing on helping identify and implement solutions to the impediments rather than simply pointing out problems and then helicoptering away.
- pmoriarty 4y ago
  "It cannot be understated, removing the GIL will be a HUGE deal for Python! It's an ugly wart which has existed for about 30 years, and nobody else has produced and delivered a working solution to the community." If it's such a huge game changer why don't some of the large enterprises which rely on Python fund this work?
  - deleted 4y ago
    [deleted]
  - meta_throwaway 4y ago
    that's exactly what has happened. edit: not sure why I got flagged, HN. Software engineer hours == funding.
  - ianai 4y ago
    Well, I might prefer a gofundme for some devs to do it. That way us average Joe’s can pitch into the support. Otherwise, there’s making a fork and attempting periodic updates from python. That’d be a huge undertaking though. FTA: “”” A lot of the value of Python is the ecosystem, not just the language… CPython really leads the way in terms of the community moving as a block. "Removing the GIL is a really transformative step. Most Python programs just don’t use threads at the moment if they want to run on multiple cores. If nogil is to be a success, the community as a whole has to buy into it." – Sam Gross”””
devnull3 4y ago
For the change of this magnitude, a compiler flag (default = OFF) is reasonable. Once the extensions and eco-system in general catches-up the flag can be a runtime one (default = OFF)
divbzero 4y ago
> There was also a large amount of concern from the attendees about the impact the introduction of nogil could have on CPython development. Some worried that introducing nogil mode could mean that the number of tests run in CI would have to double. Others worried that the maintenance burden would significantly increase if two separate versions of CPython were supported simultaneously: one with the GIL, and one without. This seems like a key consideration for the long-term success of nogil and CPython. The Python ecosystem has survived and recovered from past forks but it would good to avoid forks altogether if possible, especially if nogil proves to be stable and performant enough for prime time. At the least we should try to keep any forks short-term, e.g. starting with a compiler flag with a timeline for shifting to a runtime flag. (These are just my thoughts, take everything with a pinch of salt.)
- justahuman74 4y ago
  No GIL should be "python 4.0"
  - deleted 4y ago
    [deleted]
  - __turbobrew__ 4y ago
    Please no. I will quit python if they do another breaking major version change.
    - nhumrich 4y ago
      It doesn't have to be breaking for a 4.0 label.
  - orangepurple 4y ago
    Semantic Versioning 2.0.0 Summary Given a version number MAJOR.MINOR.PATCH, increment the: MAJOR version when you make incompatible API changes -------- Considering semver and that this is a COMPATIBLE API change, it does not warrant an increment to 4.x
ledauphin 4y ago
in my opinion, getting rid of the GIL is the one thing that Python can do to stave off Julia's eventual dominance of numeric computing. Not indefinitely, but by at least 5 years. There are still many cases when data scientists don't have a C extension and need to run pure Python functions in parallel, and the GIL makes this an order of magnitude harder (and sometimes slower). I think the core Python devs have gotten rather too conservative in the language's old age.
- Areading314 4y ago
  wouldn't removing the GIL cause all sorts of sudden race conditions and regressions in existing python code? I think there is a valid argument to keeping the GIL just for simplicity's sake
  - bratao 4y ago
    From my understanding, race conditions already exists today as the GIL is made to protect the internal Python structures. It only made it appears more infrequently.
    - masklinn 4y ago
      > It only made it appears more infrequently. It makes some operations atomic which is quite relevant.
      - MrJohz 4y ago
        Fewer than people expect. For example, the += operator looks atomic, but under the hood, it's made up of multiple python bytecode instructions, so the GIL won't apply here.
        masklinn 4y ago
        > For example, the += operator looks atomic, but under the hood, it's made up of multiple python bytecode instructions, so the GIL won't apply here. Sure, but any call to a native function which doesn’t release the gil (which is most of them at least for the builtins) is currently atomic so something like dict.setdefault.
simonw 4y ago
I tried the nogil branch out a couple of weeks ago, after running into a GIL issue with some of my code. I used the Docker image they provide. It worked! I was stunned at how easy and effective it was. My page load time dropped from 77ms to 47ms when I ran some of the code in parallel. I wrote some notes on that here: https://simonwillison.net/2022/May/6/weeknotes/#nogil https://simonwillison.net/2022/May/6/weeknotes/#nogil
- aspyct 4y ago
  It may work for your codebase, but the GIL has deep implications for any multithreaded code. For a long time now we've relied on the GIL for some level of thread safety. I'm afraid removing it would cause quite a few libraries to fail in unexpected ways.
  - josefx 4y ago
    Can you name one library affected by the change?
    - ptx 4y ago
      One example off the top of my head is socketserver in the standard library, which is used by http.server, xmlrpc, IDLE and all kinds of things. The socketserver.BaseServer class sets self.__shutdown_request in one thread and expects it to be picked up by another. In the Java memory model this variable would have to be marked as volatile (or the methods involved as synchronized) to make sure that the other thread will actually see the change, so unless Python implicitly make every variable volatile (does it?) this wouldn't be guaranteed to work (although it would probably mostly still work most of the time except for when it mysteriously doesn't).
      - eesmith 4y ago
        Setting self.__shutdown_request is atomic, assuming it's the default setter implementation. The nogil development uses biased reference counting, with an atomic lock between threads, and doesn't change that behavior.
CyberRabbi 4y ago
Every conversation on nogil needs to include some dialogue about how it works and what types of changes it requires, both to code and the mental model of the code. I can’t really further consider this or get excited about it unless I understand how it’s going to work and how it addresses previous issues with removimg the Gil.
- make3 4y ago
  there are lots of articles on the subject, your can use Google
inertially 4y ago
smetj 4y ago
Come on cpython ... be bold.
- chrsig 4y ago
  ehhh....the last time they were bold, it didn't work out too well. that said, I'd like to see the GIL removed.
jeanlou 4y ago
What does our benevolent dictator has to say about this? It seems to me that it's for these kind of undecided situation that we would need one
- nhumrich 4y ago
  He has retired. Python doesn't have a BDFL anymore.
  - threatripper 4y ago
    Still, he could speak.
    - digisign 4y ago
      He did and was cautiously optimistic on the mailing list.
  - aspyct 4y ago
    Hasn't he been hired my Microsoft recently, to work on python again?
    - eesmith 4y ago
      But not as the benevolent dictator.
Nasreddin_Hodja 4y ago
Why not to just write in Cython?
- ahurmazda 4y ago
  Now that’s funny!
ggm 4y ago
I tend to pick up bad memes like crazy. One I picked up some decades ago is that FP has a useful property in this context: it preserves parallelism to remarkably late in the code, such that you can safely understand the impact of async applied to your code. The lack of first class FP, beyond the type checking stuff, may actually at root be part of the problem: if Python had somehow become the FP rich language it said "nope, different model" -then parallelism and GIL would be a totally different argument. Maybe I was mis-informed. FP interests me but I am not rich in experience. Maybe its an oversold idea?
- moonchild 4y ago
  Anecdote: J might be called functional--it does permit global side effects, but discourages them and encourages immutable patterns. We are currently working on threading support. There is no GIL.
- Scarblac 4y ago
  What feature of FP that is missing in Python do you mean?
  - pharmakom 4y ago
    Writing FP style Python is a bad idea because the runtime is not optimizer for that. Function calls have high overhead and I don't think it has TCO? More generally, you don’t have immutability / value semantics by default.
    - Matumio 4y ago
      I think list comprehensions (and generator expressions) already do (or did, in the past?) classify as FP. In this context it seems a bit misleading to care about function call overhead (except for TCO) because Python is so slow overall. I'm usually seeing 30x when translating to C. (For pure Python of course, not PyPy or code making good use of numpy.)
      - pharmakom 4y ago
forgotpwd16 4y ago
An explanation of GIL and requirements for removing it exists in Python Wiki: https://wiki.python.org/moin/GlobalInterpreterLock https://wiki.python.org/moin/GlobalInterpreterLock
- js2 4y ago
  Though the fundamental issues with the GIL haven't changed, that page hasn't been updated in quite some time and the recent discussions section at the bottom doesn't mention the current attempt under discussion: https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsDFosB5e6BfnXLlejd9l0/edit https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsD...
antman 4y ago
For anyone who wants to test it: docker run -it nogil/python
kwyjibo12345 4y ago
I love python, but the GIL is IMHO the second worst early design decision ever made right after introducing Null pointers in Java.
otagekki 4y ago
Removing the GIL is surely a breaking change although not exactly a syntactic one. Putting it as Python 4.0 should clear the doubts and allow for widespread release without breaking existing code
klibertp 4y ago
What about all the scripts and programs that depend on the GIL to give correct results - often without even their authors knowing about it? I guess making this opt-in with a compiler flag is ok, but I would be very, very careful about making it the default. If that ever happens, we will be one Python interpreter upgrade from Y2K-like disaster...
- danbala 4y ago
  almost like people should test their code before using a new python version in production.
  - klibertp 4y ago
    That's the problem: the kind of issues the GIL prevents is notoriously hard to reproduce and debug. It would probably pass 90% of the test suites out there, unless you wrote yours with multi-threading in mind. Same for empirical tests by QA teams - they rarely cause enough load on the system for the bugs to surface. I might be too pessimistic here, but this really looks to me like a disaster waiting to happen...
  - gcbirzan 4y ago
    Because concurrency issues are notoriously easy to catch.
  - alkonaut 4y ago
    Testing can’t prove the absence of bugs.
- js2 4y ago
  FUD. This effort is very carefully designed so that such programs continue to operate correctly. https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsDFosB5e6BfnXLlejd9l0/edit https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsD...
jhidding 4y ago
There is so much hate here for the GIL, which is undeserved. You tend to not notice all the nice safety it gives you. If you want to speed up your Python code you could of course try to make it run in parallel: congratulations, you just wasted N times more CPU on slow interpreted code. You could have used an accellerator language like Numba, or write parts of your code in C++ or Rust and get a 10-100 times speedup on a single core!
- js2 4y ago
  FUD. This effort is designed to get the benefits of the GIL without its costs. It is very carefully designed. https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsDFosB5e6BfnXLlejd9l0/edit https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsD...
  - UncleEntity 4y ago
    You can’t just call everything that doesn’t agree with your opinion FUD… Because, you know, they make a valid (flamebatish) point, the ‘easiest’ way to get performance out of python is to wrap the critical code in another language as an extension. Removing the GIL isn’t going to change this no matter how careful it is designed.
    - josefx 4y ago
      FUD isn't just a meaningless phrase, it means fear, uncertainty and doubt. Nearly every comment against GIL removal makes vague claims about this causing stability issues in a large amount of code that possibly, might, perhaps depend on it without even being aware of it. Yet there is not a single example given that holds up to even basic scrutiny. This is quite literally a textbook case of FUD.
  - carapace 4y ago
    This is the third time you've replied to someone with this exact comment. Please don't do that. You are not being as effective at promoting your POV as you might be if you were a little more tactful. I read the document. Sam Gross seems to have a clear grasp on the risks associated with this kind of project (I would quote the relevant part, but google docs is a clown shoe.) One the one hand I wish him luck. If he pulls it off he'll be a hero. On the other hand this seems like a huge "turd polishing" for a problem that one only encounters if one is doing something ill-advised. The GIL just isn't that big of a problem in practice. I've been writing Python for going on twenty years without ever encountering a single problem due to the GIL.
js2 4y ago
Folks, the whole point of this effort and what stands it apart from previous GIL-removal efforts is that it's carefully designed to: 1. Give the performance-benefits of GIL removal for multi-threaded code. 2. Not hurt the performance of single-threaded code, hopefully improving it too. 3. Not break any pure Python code that relies on the semantics of the GIL. 4. Minimize impact to extensions. If you're commenting here that this is going to break things w/o having read the design doc, you're contributing FUD. It's disappointing to see the discussion go this way. Here's Sam's design doc: https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsDFosB5e6BfnXLlejd9l0/edit https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsD... Some highlights: The project aims for a concurrency model that matches the threads + shared memory model implemented in common operating systems and in programming languages like Java, C++, and Swift. We also aim for similar safety guarantees to Java and Go -- the language doesn’t prevent data races, but data races in user code do not corrupt the VM state. (Notably, Swift and C++ do not have this property: data races in those languages may corrupt VM state leading to segfaults). This strikes a balance between safety and performance. Weaker guarantees, like in Swift and C++, can make debugging difficult, while much stronger guarantees can limit flexibility or hamper performance. Compatibility: The vast majority of Python programs should not require any changes to Python code to continue working. Most of the issues I have encountered so far are due to being based on 3.9.0a3 and libraries using features from the 3.9 final release. A few of the issues have been due to changes to code object internals or the bytecode format, but so far I have been able to address those by making changes to the interpreter to improve backwards compatibility. All extensions that use the Python C API will require re-compilation, even the few that are limited to the stable ABI. (The reference counting changes do not preserve the stable ABI). To compile successfully, some C API extensions will need minor modifications, typically replacement of direct access of PyObject reference count fields with the Py_REFCNT macro. To run successfully, some C API extensions need modifications to protect global data structures in C code that were previously protected by the GIL. For an example, see these two patches to NumPy.
CivBase 4y ago
What ever happened to PEP 554? I remember reading about that and thinking it was a pretty elegant solution to the GIL. I thought I saw something a while ago about it being expected in an upcoming version, but I see it's still in draft. https://peps.python.org/pep-0554/ https://peps.python.org/pep-0554/
carapace 4y ago
I don't mean to troll, but I have to say the GIL is not and never has been a problem with Python. It's weird to me that this one tiny issue has grown into such a big waste of time, energy, and attention. I've written Python for something like twenty years now and never once had a problem due to the GIL. It's a classic case of "you're doing it wrong": Python supports concurrency in several useful ways, and specifically does NOT support it in one particular very useful way. If you have somehow arranged to bang your head on that one specific thing that Python doesn't do, and you cannot figure out how to not bang your head on the GIL, then for goodness' sake use Go or Erlang or something that DOES do the one thing you can't live without. - - - - Don't get me wrong. If this succeeds it will be a great thing. This effort seems well-thought out, and I wish Sam Gross luck and success.
malkia 4y ago
Sounds like it should be in python4 - that's going to break a lot of assumptions...
iknownothow 4y ago
As someone who only knows Python, this gives me existential angst. Like some other people have pointed out, I think the GIL is secret sauce to Python's success. I would be vary of the religious fervor behind taking the GIL to the gallows. It's hard to put to words what the GIL does for Python. I think the best I can do is to point to Rust and ask you to consider what Rust's number one claim to fame is? A more than significant part of Rust's bible ("the book") is about memory ownership. Python's GIL lets me be completely ignorant of these issues and all my brain cells just focus on the problem at hand. My long term livelihood and sanity is at stake here and I really appreciate that some of core maintainers of Python are taking their time and thinking deeply about the implications of removing the GIL. Python with the big bad GIL has become the most popular language in recent years. And it's gotten there slowly and steadily over 20 years. The most popular language just so happens to be the only (?) language that is single threaded.

304 points by bratao 4y ago

gjvc 4y ago
why are you shilling julia in a thread about the python GIL?
- moelf 4y ago
  :
  - gjvc 4y ago
    many successful projects and businesses can directly attribute their success to choosing and using python, in contrast to your unsubstantiated opinions. you are shouting into the void, and looking foolish while doing so.
  - blindseer 4y ago
    I genuinely think the Julia community should have guidelines on how to act on a public forum when advocating for Julia. I've had so many instances of being rubbed the wrong way from Julia folk. In some ways, it is as annoying as the RIIR folk, but it just happens to be a smaller number of people. I for one am excited to see the GIL-ectomy work come to the stage that it is today. I followed Larry Hasting's work back in 2016/2017, and I'm glad to see Sam has taken the mantle with Larry's blessing.
    - gjvc 4y ago
      case in point here; guy just edits his comments down to a colon and disappears without a word. the thing which makes this forgivable to me about this kind of astroturfing / shilling / etc is that the people doing it really do believe they are doing good when they are doing it and they don't believe for a moment that other people will see what they are doing for what it is.

> “We need to lay out a plan of how to proceed,” remarked Pablo Galindo Salgado. “Just creating a PR with 20,000 lines of code changed is infeasible.” One of the saddest things about popular open-source projects like Python is how inevitably the maintainers become worn down and jaded over time, due to constantly filtering and protecting Python from dumb or nonsensical ideas. Then when something like this comes along, a true game changer, maintainers have no energy or goodwill left to collaborate on these infinitely important initiatives, like removing the dogdamn GIL. This is way more significant than everything I'm aware of that's happened since the birth of the language. All other things have been, trivial miuntiae in comparison. It bears repeating: "everything else has been trivial minutiae in comparison to a GIL-ectamy for Python." It cannot be understated, removing the GIL will be a HUGE deal for Python! It's an ugly wart which has existed for about 30 years, and nobody else has produced and delivered a working solution to the community. I wish Team Python would welcome GIL Eradication with open arms and a supportive attitude. This would look like focusing on helping identify and implement solutions to the impediments rather than simply pointing out problems and then helicoptering away.

pmoriarty 4y ago
"It cannot be understated, removing the GIL will be a HUGE deal for Python! It's an ugly wart which has existed for about 30 years, and nobody else has produced and delivered a working solution to the community." If it's such a huge game changer why don't some of the large enterprises which rely on Python fund this work?
- deleted 4y ago
  [deleted]
- meta_throwaway 4y ago
  that's exactly what has happened. edit: not sure why I got flagged, HN. Software engineer hours == funding.
- ianai 4y ago
  Well, I might prefer a gofundme for some devs to do it. That way us average Joe’s can pitch into the support. Otherwise, there’s making a fork and attempting periodic updates from python. That’d be a huge undertaking though. FTA: “”” A lot of the value of Python is the ecosystem, not just the language… CPython really leads the way in terms of the community moving as a block. "Removing the GIL is a really transformative step. Most Python programs just don’t use threads at the moment if they want to run on multiple cores. If nogil is to be a success, the community as a whole has to buy into it." – Sam Gross”””

devnull3 4y ago

For the change of this magnitude, a compiler flag (default = OFF) is reasonable. Once the extensions and eco-system in general catches-up the flag can be a runtime one (default = OFF)

divbzero 4y ago

> There was also a large amount of concern from the attendees about the impact the introduction of nogil could have on CPython development. Some worried that introducing nogil mode could mean that the number of tests run in CI would have to double. Others worried that the maintenance burden would significantly increase if two separate versions of CPython were supported simultaneously: one with the GIL, and one without. This seems like a key consideration for the long-term success of nogil and CPython. The Python ecosystem has survived and recovered from past forks but it would good to avoid forks altogether if possible, especially if nogil proves to be stable and performant enough for prime time. At the least we should try to keep any forks short-term, e.g. starting with a compiler flag with a timeline for shifting to a runtime flag. (These are just my thoughts, take everything with a pinch of salt.)

justahuman74 4y ago
No GIL should be "python 4.0"
- deleted 4y ago
  [deleted]
- __turbobrew__ 4y ago
  Please no. I will quit python if they do another breaking major version change.
  - nhumrich 4y ago
    It doesn't have to be breaking for a 4.0 label.
- orangepurple 4y ago
  Semantic Versioning 2.0.0 Summary Given a version number MAJOR.MINOR.PATCH, increment the: MAJOR version when you make incompatible API changes -------- Considering semver and that this is a COMPATIBLE API change, it does not warrant an increment to 4.x

ledauphin 4y ago

in my opinion, getting rid of the GIL is the one thing that Python can do to stave off Julia's eventual dominance of numeric computing. Not indefinitely, but by at least 5 years. There are still many cases when data scientists don't have a C extension and need to run pure Python functions in parallel, and the GIL makes this an order of magnitude harder (and sometimes slower). I think the core Python devs have gotten rather too conservative in the language's old age.

Areading314 4y ago
wouldn't removing the GIL cause all sorts of sudden race conditions and regressions in existing python code? I think there is a valid argument to keeping the GIL just for simplicity's sake
- bratao 4y ago
  From my understanding, race conditions already exists today as the GIL is made to protect the internal Python structures. It only made it appears more infrequently.
  - masklinn 4y ago
    > It only made it appears more infrequently. It makes some operations atomic which is quite relevant.
    - MrJohz 4y ago
      Fewer than people expect. For example, the += operator looks atomic, but under the hood, it's made up of multiple python bytecode instructions, so the GIL won't apply here.
      - masklinn 4y ago
        > For example, the += operator looks atomic, but under the hood, it's made up of multiple python bytecode instructions, so the GIL won't apply here. Sure, but any call to a native function which doesn’t release the gil (which is most of them at least for the builtins) is currently atomic so something like dict.setdefault.

simonw 4y ago

I tried the nogil branch out a couple of weeks ago, after running into a GIL issue with some of my code. I used the Docker image they provide. It worked! I was stunned at how easy and effective it was. My page load time dropped from 77ms to 47ms when I ran some of the code in parallel. I wrote some notes on that here: https://simonwillison.net/2022/May/6/weeknotes/#nogil https://simonwillison.net/2022/May/6/weeknotes/#nogil

aspyct 4y ago
It may work for your codebase, but the GIL has deep implications for any multithreaded code. For a long time now we've relied on the GIL for some level of thread safety. I'm afraid removing it would cause quite a few libraries to fail in unexpected ways.
- josefx 4y ago
  Can you name one library affected by the change?
  - ptx 4y ago
    One example off the top of my head is socketserver in the standard library, which is used by http.server, xmlrpc, IDLE and all kinds of things. The socketserver.BaseServer class sets self.__shutdown_request in one thread and expects it to be picked up by another. In the Java memory model this variable would have to be marked as volatile (or the methods involved as synchronized) to make sure that the other thread will actually see the change, so unless Python implicitly make every variable volatile (does it?) this wouldn't be guaranteed to work (although it would probably mostly still work most of the time except for when it mysteriously doesn't).
    - eesmith 4y ago
      Setting self.__shutdown_request is atomic, assuming it's the default setter implementation. The nogil development uses biased reference counting, with an atomic lock between threads, and doesn't change that behavior.

CyberRabbi 4y ago

Every conversation on nogil needs to include some dialogue about how it works and what types of changes it requires, both to code and the mental model of the code. I can’t really further consider this or get excited about it unless I understand how it’s going to work and how it addresses previous issues with removimg the Gil.

make3 4y ago
there are lots of articles on the subject, your can use Google

inertially 4y ago

smetj 4y ago

Come on cpython ... be bold.

chrsig 4y ago
ehhh....the last time they were bold, it didn't work out too well. that said, I'd like to see the GIL removed.

jeanlou 4y ago

What does our benevolent dictator has to say about this? It seems to me that it's for these kind of undecided situation that we would need one

nhumrich 4y ago
He has retired. Python doesn't have a BDFL anymore.
- threatripper 4y ago
  Still, he could speak.
  - digisign 4y ago
    He did and was cautiously optimistic on the mailing list.
- aspyct 4y ago
  Hasn't he been hired my Microsoft recently, to work on python again?
  - eesmith 4y ago
    But not as the benevolent dictator.

Nasreddin_Hodja 4y ago

Why not to just write in Cython?

ahurmazda 4y ago
Now that’s funny!

ggm 4y ago

I tend to pick up bad memes like crazy. One I picked up some decades ago is that FP has a useful property in this context: it preserves parallelism to remarkably late in the code, such that you can safely understand the impact of async applied to your code. The lack of first class FP, beyond the type checking stuff, may actually at root be part of the problem: if Python had somehow become the FP rich language it said "nope, different model" -then parallelism and GIL would be a totally different argument. Maybe I was mis-informed. FP interests me but I am not rich in experience. Maybe its an oversold idea?

moonchild 4y ago
Anecdote: J might be called functional--it does permit global side effects, but discourages them and encourages immutable patterns. We are currently working on threading support. There is no GIL.
Scarblac 4y ago
What feature of FP that is missing in Python do you mean?
- pharmakom 4y ago
  Writing FP style Python is a bad idea because the runtime is not optimizer for that. Function calls have high overhead and I don't think it has TCO? More generally, you don’t have immutability / value semantics by default.
  - Matumio 4y ago
    I think list comprehensions (and generator expressions) already do (or did, in the past?) classify as FP. In this context it seems a bit misleading to care about function call overhead (except for TCO) because Python is so slow overall. I'm usually seeing 30x when translating to C. (For pure Python of course, not PyPy or code making good use of numpy.)
    - pharmakom 4y ago

forgotpwd16 4y ago

An explanation of GIL and requirements for removing it exists in Python Wiki: https://wiki.python.org/moin/GlobalInterpreterLock https://wiki.python.org/moin/GlobalInterpreterLock

js2 4y ago
Though the fundamental issues with the GIL haven't changed, that page hasn't been updated in quite some time and the recent discussions section at the bottom doesn't mention the current attempt under discussion: https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsDFosB5e6BfnXLlejd9l0/edit https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsD...

antman 4y ago

For anyone who wants to test it: docker run -it nogil/python

kwyjibo12345 4y ago

I love python, but the GIL is IMHO the second worst early design decision ever made right after introducing Null pointers in Java.

otagekki 4y ago

Removing the GIL is surely a breaking change although not exactly a syntactic one. Putting it as Python 4.0 should clear the doubts and allow for widespread release without breaking existing code

klibertp 4y ago

What about all the scripts and programs that depend on the GIL to give correct results - often without even their authors knowing about it? I guess making this opt-in with a compiler flag is ok, but I would be very, very careful about making it the default. If that ever happens, we will be one Python interpreter upgrade from Y2K-like disaster...

danbala 4y ago
almost like people should test their code before using a new python version in production.
- klibertp 4y ago
  That's the problem: the kind of issues the GIL prevents is notoriously hard to reproduce and debug. It would probably pass 90% of the test suites out there, unless you wrote yours with multi-threading in mind. Same for empirical tests by QA teams - they rarely cause enough load on the system for the bugs to surface. I might be too pessimistic here, but this really looks to me like a disaster waiting to happen...
- gcbirzan 4y ago
  Because concurrency issues are notoriously easy to catch.
- alkonaut 4y ago
  Testing can’t prove the absence of bugs.
js2 4y ago
FUD. This effort is very carefully designed so that such programs continue to operate correctly. https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsDFosB5e6BfnXLlejd9l0/edit https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsD...

jhidding 4y ago

There is so much hate here for the GIL, which is undeserved. You tend to not notice all the nice safety it gives you. If you want to speed up your Python code you could of course try to make it run in parallel: congratulations, you just wasted N times more CPU on slow interpreted code. You could have used an accellerator language like Numba, or write parts of your code in C++ or Rust and get a 10-100 times speedup on a single core!

js2 4y ago
FUD. This effort is designed to get the benefits of the GIL without its costs. It is very carefully designed. https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsDFosB5e6BfnXLlejd9l0/edit https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsD...
- UncleEntity 4y ago
  You can’t just call everything that doesn’t agree with your opinion FUD… Because, you know, they make a valid (flamebatish) point, the ‘easiest’ way to get performance out of python is to wrap the critical code in another language as an extension. Removing the GIL isn’t going to change this no matter how careful it is designed.
  - josefx 4y ago
    FUD isn't just a meaningless phrase, it means fear, uncertainty and doubt. Nearly every comment against GIL removal makes vague claims about this causing stability issues in a large amount of code that possibly, might, perhaps depend on it without even being aware of it. Yet there is not a single example given that holds up to even basic scrutiny. This is quite literally a textbook case of FUD.
- carapace 4y ago
  This is the third time you've replied to someone with this exact comment. Please don't do that. You are not being as effective at promoting your POV as you might be if you were a little more tactful. I read the document. Sam Gross seems to have a clear grasp on the risks associated with this kind of project (I would quote the relevant part, but google docs is a clown shoe.) One the one hand I wish him luck. If he pulls it off he'll be a hero. On the other hand this seems like a huge "turd polishing" for a problem that one only encounters if one is doing something ill-advised. The GIL just isn't that big of a problem in practice. I've been writing Python for going on twenty years without ever encountering a single problem due to the GIL.

js2 4y ago

Folks, the whole point of this effort and what stands it apart from previous GIL-removal efforts is that it's carefully designed to: 1. Give the performance-benefits of GIL removal for multi-threaded code. 2. Not hurt the performance of single-threaded code, hopefully improving it too. 3. Not break any pure Python code that relies on the semantics of the GIL. 4. Minimize impact to extensions. If you're commenting here that this is going to break things w/o having read the design doc, you're contributing FUD. It's disappointing to see the discussion go this way. Here's Sam's design doc: https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsDFosB5e6BfnXLlejd9l0/edit https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsD... Some highlights: The project aims for a concurrency model that matches the threads + shared memory model implemented in common operating systems and in programming languages like Java, C++, and Swift. We also aim for similar safety guarantees to Java and Go -- the language doesn’t prevent data races, but data races in user code do not corrupt the VM state. (Notably, Swift and C++ do not have this property: data races in those languages may corrupt VM state leading to segfaults). This strikes a balance between safety and performance. Weaker guarantees, like in Swift and C++, can make debugging difficult, while much stronger guarantees can limit flexibility or hamper performance. Compatibility: The vast majority of Python programs should not require any changes to Python code to continue working. Most of the issues I have encountered so far are due to being based on 3.9.0a3 and libraries using features from the 3.9 final release. A few of the issues have been due to changes to code object internals or the bytecode format, but so far I have been able to address those by making changes to the interpreter to improve backwards compatibility. All extensions that use the Python C API will require re-compilation, even the few that are limited to the stable ABI. (The reference counting changes do not preserve the stable ABI). To compile successfully, some C API extensions will need minor modifications, typically replacement of direct access of PyObject reference count fields with the Py_REFCNT macro. To run successfully, some C API extensions need modifications to protect global data structures in C code that were previously protected by the GIL. For an example, see these two patches to NumPy.

CivBase 4y ago

What ever happened to PEP 554? I remember reading about that and thinking it was a pretty elegant solution to the GIL. I thought I saw something a while ago about it being expected in an upcoming version, but I see it's still in draft. https://peps.python.org/pep-0554/ https://peps.python.org/pep-0554/

carapace 4y ago

I don't mean to troll, but I have to say the GIL is not and never has been a problem with Python. It's weird to me that this one tiny issue has grown into such a big waste of time, energy, and attention. I've written Python for something like twenty years now and never once had a problem due to the GIL. It's a classic case of "you're doing it wrong": Python supports concurrency in several useful ways, and specifically does NOT support it in one particular very useful way. If you have somehow arranged to bang your head on that one specific thing that Python doesn't do, and you cannot figure out how to not bang your head on the GIL, then for goodness' sake use Go or Erlang or something that DOES do the one thing you can't live without. - - - - Don't get me wrong. If this succeeds it will be a great thing. This effort seems well-thought out, and I wish Sam Gross luck and success.

malkia 4y ago

Sounds like it should be in python4 - that's going to break a lot of assumptions...

iknownothow 4y ago

As someone who only knows Python, this gives me existential angst. Like some other people have pointed out, I think the GIL is secret sauce to Python's success. I would be vary of the religious fervor behind taking the GIL to the gallows. It's hard to put to words what the GIL does for Python. I think the best I can do is to point to Rust and ask you to consider what Rust's number one claim to fame is? A more than significant part of Rust's bible ("the book") is about memory ownership. Python's GIL lets me be completely ignorant of these issues and all my brain cells just focus on the problem at hand. My long term livelihood and sanity is at stake here and I really appreciate that some of core maintainers of Python are taking their time and thinking deeply about the implications of removing the GIL. Python with the big bad GIL has become the most popular language in recent years. And it's gotten there slowly and steadily over 20 years. The most popular language just so happens to be the only (?) language that is single threaded.