David Beazley
4 HN recommenders · recommended in 8 months, 2013–2023
46:10 · 127K views · Feb 3, 2012
David Beazley's PyCon 2010 talk explains how the Python Global Interpreter Lock works and shows experiments where multithreaded code runs slower, even on more cores, due to lock contention and context-switching overhead.
The canonical recommendation for understanding the GIL, praised both for its clarity and for how well it explains a deep technical topic.
8 comments from Hacker News
"The point of such a presentation is to take a piece of code that the presenter has understood deeply and for them to help the audience understand the core ideas..." I do get lots of value out of that. My favorite example is Beazley's GIL talk: this video
I am not expert, and this might be dated information, but historically there is a "thrashing" introduced between the GIL and OS scheduled threads which has surprising performance implications. David Beazley does a much better illustrating the nuances than I ever could: this video Including a wild phenomenon where a threaded Python program's performance can degrade by increasing number of CPU cores available to a system. Coroutines avoid this by not requiring individual thread scheduling by the OS. So they effectively release the GIL like threads on IO but avoid OS level thread switching.
"I never actually got around to learning -- or even thinking about!-- what exactly the GIL is" David Beazley does a good job on explaining the GIL. There are multiple videos of his GIL talks on YouTube. This one, for instance: this video He has a page about this at [LINK]
David probably isnt the best guy for that. But here's one of the famous ones on GIL. this video Beware though, his talks are known to be devastating to the programmer, resulting in serious head injuries, trauma, headaches and other fun stuff.
> If you want speed you go to any other scripting language (other than Ruby). Ruby has historically had the same issues. Most Pythonistas I know aren't so evangelical. It's mostly a question of how to go about integrating C/C++ code. Many people complaining about the GIL (and the like) have some naive microbenchmark, don't understand the trade-offs/limitations of their runtime etc. That doesn't mean critique isn't important and required, but it's going to be better when it's properly researched and improves on the body of work out there ( this video ). > Transpiling it to another language like Google did, shows that the underlying technology is not worth much. How is this any general indicator of the worth of the language? It shows for some cases, that Google thought this was a worthwhile investment. Google has experimented for a long time with ways to improve how Python code can be run. They ran the Unladen Swallow project, but spent more time on LLVM issues at the time making it infeasible to continue the project. They'll discontinue one path and try another. None of this is really a commentary from Google on CPython, the community, or the value that it has for most people. The people working on this stuff interact in a pretty friendly basis.