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.
PEP684 may be accepted since it doesn't affect things in any meaningful way and gives you more flexibility it also doesn't slow down single thread performance at all. I don't know about PEP554 since I never used pypy. PEP703 will never be implemented as far as I know. It may be launched as library that can be download and installed throw pip but it will prob never ship with the language
@@nicholasfigueiredo3171 pep554 doesn't have anything to do with PyPy tho? Whether pep703 will get ACCEPTED remains to be seen, but in case you didn't know, it already HAS a reference implementation for CPython, so the issue isn't whether it's possible to implement, but rather if it's WORTH IT. In particular, the current pep703 implementation breaks ABI with some old-style C extensions. Last time I've checked, there were quite some heated discussions around it on the official discourse and GH. It's quite possible that nothing useful will come out of pep703, but at this point in time it's hard to say one way or the other. Also, the in-process sub interpreters with separate GILs are already accepted and I have high hopes as they should allow for some multi-threaded applications that currently suck due to GIL contention and/or multiprocessing serialization/deserialization overhead.
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!
I couldn't find any article on that; however that would be very intersting! Getting around the gil with external libraries is definitely doable, it just depends on how much you care about the performance. Thanks for watching!
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.
Yeah check PEP684 it would prob solve this problem it also makes the language very slighted faster because it reduces the use internal use of global variables, I believe it will be implemented at some point
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!
No, the JVM does not have a mutex on every object. You can synchronize on objects but it's a deliberate action. Not sure if there are concurrency issues that may occur in Jython that you don't have in Python.
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
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?!?
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.
0:03 hold my py 3.13 😂
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.
PEP684 may be accepted since it doesn't affect things in any meaningful way and gives you more flexibility it also doesn't slow down single thread performance at all. I don't know about PEP554 since I never used pypy. PEP703 will never be implemented as far as I know. It may be launched as library that can be download and installed throw pip but it will prob never ship with the language
@@nicholasfigueiredo3171 pep554 doesn't have anything to do with PyPy tho? Whether pep703 will get ACCEPTED remains to be seen, but in case you didn't know, it already HAS a reference implementation for CPython, so the issue isn't whether it's possible to implement, but rather if it's WORTH IT.
In particular, the current pep703 implementation breaks ABI with some old-style C extensions. Last time I've checked, there were quite some heated discussions around it on the official discourse and GH.
It's quite possible that nothing useful will come out of pep703, but at this point in time it's hard to say one way or the other. Also, the in-process sub interpreters with separate GILs are already accepted and I have high hopes as they should allow for some multi-threaded applications that currently suck due to GIL contention and/or multiprocessing serialization/deserialization overhead.
1:20 python uses both reference counting and mark-and-sweep for GC
reference counting can't handle reference cycles between unreachable objects
I chuckled at * GIL is not going anytime soon *. Meta just promised to invest 3 years' worth of engineering hours
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!
I couldn't find any article on that; however that would be very intersting! Getting around the gil with external libraries is definitely doable, it just depends on how much you care about the performance. Thanks for watching!
Thank you for this video, it’s really well made! Helped me understand why the GIL is there.
Why does the reference count of the last line at 1:48 equal 0
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.
Yeah check PEP684 it would prob solve this problem it also makes the language very slighted faster because it reduces the use internal use of global variables, I believe it will be implemented at some point
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!
Jython is python2
No, the JVM does not have a mutex on every object. You can synchronize on objects but it's a deliberate action. Not sure if there are concurrency issues that may occur in Jython that you don't have in Python.
That's was a bit harsh on Lisp :) But thanks, video and explanation are beautiful
The only thing python really needs from you is this: to find your own way to solve things by loving your mistakes
Nice. Thanks!
Great video.
You've never had a problem with cyclic references because Python has a garbage collector in addition to the reference counting.
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
Lisp isn't relevant? Are you kiddin? Do you even know about Clojure's existance?
Awesome
The fifth who came
When we getting a discord server?
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?!?
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.
Third
First
second