Does Python Really Need the GIL

Python is a great language that can do almost anything. Its ease of use has been one of its greatest features. The Global Interpreter Lock is the opposite and can make it confusing to understand why multithreading doesn't work as you would expect.

If you like the video consider subscribing for more like these!

0:00 GIL?
0:56 GIL Uses
1:10 Reference Counting
2:04 Multithreading
3:03 Numpy/IO threads
3:46 Why GIL can't be removed

#python #programming #software

[sudhamshuhosamane]

I chuckled at * GIL is not going anytime soon *. Meta just promised to invest 3 years' worth of engineering hours

[ruroruro]

This video is weirdly insistent on "GIL not going anywhere". Especially given that there's been a lot of recent PEPs that work on removing the GIL (or working around it).

For example:

- PEP684 (already accepted for Python 3.12) makes the GIL per-interpreter instead of per-process. With this, you can spawn multiple separate python interpreters in the same process and these interpreters will have independent locks, allowing them to run in parallel threads.

- PEP554 (currently in draft for Python 3.13) provides a standard API for starting such separate interpreters from pure Python (with pure PEP684 the only way to spawn new interpreters is from the C-API afaik).

- PEP703 (currently in draft for Python 3.13) provides a way to completely remove the GIL (though you would have to opt-in to disabling the GIL, because old C-API extensions are not ABI compatible with nogil).

Of course, these PEPs might not get accepted in the end, but not even mentioning this and insisting on the GIL being "not removable" is a really weird choice. Makes it seem like you didn't do the proper research for the video.

[ko-Daegu]

1:20 python uses both reference counting and mark-and-sweep for GC
reference counting can't handle reference cycles between unreachable objects

[ControlProblem]

You've never had a problem with cyclic references because Python has a garbage collector in addition to the reference counting.

[marlomew]

Thank you for this video, it’s really well made! Helped me understand why the GIL is there.

[moo_goo]

i believe a test was once run using asyncio to call as many null actions as possible just to see how fast can the gil perform at max capacity and it was found to be half a million actions per second.
Youll need to find that article if its actually true, but when i heard that it kinda confirmed for me that gil isnt the actual bottle neck in most non-application scenarios.
even using libraries like polars shows there are unique methods to get around the whole concept as whole with lazy processes. Great video!

[thomasstokes]

Why does the reference count of the last line at 1:48 equal 0

[marksto]

Lisp isn't relevant? Are you kiddin? Do you even know about Clojure's existance?

[Verrisin]

Not having multithreading is usually not a big deal anyway, as multiple threads mutating the same memory is pretty awful to begin with.
- Better aproach is message passing and separate processes* like JS or Erlang.
(* you can implement those processes as "threads" to avoid IPC, but to the programmer they look like entirely separate memory spaces)
- Immutable message passing FTW.

[ivankudinov]

That's was a bit harsh on Lisp :) But thanks, video and explanation are beautiful

[catalinancutei]

Doesn't the JVM have some sort of mutex on every object? So using jython to get rid of the GIL just moves the mutex from python implementation to JVM I think.
Anyway, great video!

[gusnemides]

The only thing python really needs from you is this: to find your own way to solve things by loving your mistakes

[Ackerhon]

The fifth who came

When we getting a discord server?

[alangamer]

Kinda unrelated but, even if Jython supports true multithreading, wouldn't it still be slower than Cpython? After all Java, as a weird amalgamation of interpreted and compiled, is much slower than C, so even if it scales better, I think you're better off using one fast core on Cpython than 4 slower cores on Jython

[Verrisin]

um ... JVM is pretty good (if not using the Java language itself)
lisp is great (and people very much still use it)
and the title is very much clickbait and the video had nothing but common knowledge (not even up to date) and bad takes ...
Sorry for being negative, but I am ... annoyed.

[itellyouforfree]

0:59 "having a GIL allows single threaded code to run much faster" ahahah just LOL, did you forget you are talking about the SLOWEST language ever invented by mankind?!?