6 ms·

No more fucking GIL bullshits

by stevefan1999 5y ago

dralley 5y ago
It doesn't have a GIL because it's using a lot of smaller individual locks. That ends up being much slower in practice.
Jeff_Brown 5y ago
Oh, that's a big deal, yes. (For those unaware, GIL = global interpreter lock.)
- reikonomusha 5y ago
  I don’t think it’s a big deal if it’s not backwards compatible with the billions of lines of existing Python which use C extensions.
- BiteCode_dev 5y ago
  It's most likely that the GIL will be removed in the next 5 years: https://docs.google.com/document/u/0/d/18CXhDb1ygxg-YXNBJNzfzZsDFosB5e6BfnXLlejd9l0/mobilebasic https://docs.google.com/document/u/0/d/18CXhDb1ygxg-YXNBJNzf...
prabhu-yu 5y ago
Are you sure, this does not have the GIL? I tried looking into documentation, I could not find such info. Can you please point the link?
- the_mitsuhiko 5y ago
  It does not have a GIL but this also means it's not compatible with a lot of Python code that needs a GIL or C-extensions. Not having a GIL by itself is not tricky, being compatible and not having a GIL is.
  - abledon 5y ago
    why can't they implement a 'fake' GIL flag for those programs? so its backward compatible. (Yeah its probably a lot more work to write those extra modules/code paths... !)
    - Joker_vD 5y ago
      It's not a "flag", really: it's a fundamental, implicit underlying assumption about the execution environment. The C extensions assume (roughly) that if they're executing, they can touch any part of the runtime without any synchronization whatsoever, because nobody else is executing (that's what GIL ensures).
      - jerf 5y ago
        Or, to put it another way, it's the first letter of the acronym: "Global Interpreter Lock". You can't really "fake" a global lock. Either you're globally locking everywhere with the global lock or you aren't.
  - hannibalhorn 5y ago
    I believe Python C-API compatibility isn't a really a goal for this implementation anyway. [1] HPy sounds like the best path forward? 1. https://github.com/RustPython/RustPython/issues/1940 https://github.com/RustPython/RustPython/issues/1940
BiteCode_dev 5y ago
It has a GIL for now. But if you are interested on removing the GIL, you gonna love 2022: https://docs.google.com/document/u/0/d/18CXhDb1ygxg-YXNBJNzfzZsDFosB5e6BfnXLlejd9l0/mobilebasic https://docs.google.com/document/u/0/d/18CXhDb1ygxg-YXNBJNzf...

No more fucking GIL bullshits

dralley 5y ago

It doesn't have a GIL because it's using a lot of smaller individual locks. That ends up being much slower in practice.

Jeff_Brown 5y ago

Oh, that's a big deal, yes. (For those unaware, GIL = global interpreter lock.)

reikonomusha 5y ago
I don’t think it’s a big deal if it’s not backwards compatible with the billions of lines of existing Python which use C extensions.
BiteCode_dev 5y ago
It's most likely that the GIL will be removed in the next 5 years: https://docs.google.com/document/u/0/d/18CXhDb1ygxg-YXNBJNzfzZsDFosB5e6BfnXLlejd9l0/mobilebasic https://docs.google.com/document/u/0/d/18CXhDb1ygxg-YXNBJNzf...

prabhu-yu 5y ago

Are you sure, this does not have the GIL? I tried looking into documentation, I could not find such info. Can you please point the link?

the_mitsuhiko 5y ago
It does not have a GIL but this also means it's not compatible with a lot of Python code that needs a GIL or C-extensions. Not having a GIL by itself is not tricky, being compatible and not having a GIL is.
- abledon 5y ago
  why can't they implement a 'fake' GIL flag for those programs? so its backward compatible. (Yeah its probably a lot more work to write those extra modules/code paths... !)
  - Joker_vD 5y ago
    It's not a "flag", really: it's a fundamental, implicit underlying assumption about the execution environment. The C extensions assume (roughly) that if they're executing, they can touch any part of the runtime without any synchronization whatsoever, because nobody else is executing (that's what GIL ensures).
    - jerf 5y ago
      Or, to put it another way, it's the first letter of the acronym: "Global Interpreter Lock". You can't really "fake" a global lock. Either you're globally locking everywhere with the global lock or you aren't.
- hannibalhorn 5y ago
  I believe Python C-API compatibility isn't a really a goal for this implementation anyway. [1] HPy sounds like the best path forward? 1. https://github.com/RustPython/RustPython/issues/1940 https://github.com/RustPython/RustPython/issues/1940

BiteCode_dev 5y ago

It has a GIL for now. But if you are interested on removing the GIL, you gonna love 2022: https://docs.google.com/document/u/0/d/18CXhDb1ygxg-YXNBJNzfzZsDFosB5e6BfnXLlejd9l0/mobilebasic https://docs.google.com/document/u/0/d/18CXhDb1ygxg-YXNBJNzf...