Skip to content
Hallway
0:00 / 0:00

#gil#globalinterpreterlock#gilectomy

Larry Hastings - Removing Python's GIL: The Gilectomy - PyCon 2016

PyCon 2016

15K subscribers • 8 videos on Hallway

YouTube
  • Recommended by 6 people: 5 on Hacker News and 1 curated list.
  • A classic. People kept recommending it from 2016 to 2023.
  • Presented by Larry Hastings
  • Linked in the descriptionPyCon/2016-slides

Advanced. Deep dive for people who know the field.

48K views10 years ago6 recommendations

Programming languagesSystems programmingPythonConcurrency and parallelismPerformance and optimization

Larry Hastings explains the design of Python's Global Interpreter Lock and his efforts to remove it in the Gilectomy project.

Speaker: Larry Hastings You've heard of Python's ""GIL""... but what is it? What problems does it solve? How does it work? What are the ramifications of its design? Attendees should have a basic knowledge of multithreaded programming. Understanding C is helpful but not required. Slides can be found at: speakerdeck.com/pycon2016 and github.com/PyCon/2016-slides

Why it's here

6 people recommend this

What people say. Recommended as an insightful deep dive into the CPython interpreter, the GIL, and the performance trade-offs of removing it.

gshulegaardon Hacker News • Recommends

On “Let's Remove the Global Interpreter Lock”

…the biggest flaw with Python...but over time I care less and less about it. I think the first thing to realize is that single-threaded performance is often significantly better with the GIL than without it. I think Larry Hasting's first Gilectomy talk was extremely insightful (about the GIL in general and about performance when removing the GIL): link to this video I am not sure I would, personally, trade single-threaded performance for enabling multi-threaded applications. I view Python as a high-level rapid prototyping language that is well suited for business logic and glue code. And for that type of workload I would value single-threaded performance over support for multi-threading. Even now, a ye…
View on Hacker News

programming-talkscurated list on GitHubRecommends

Under “Python”

Removing Python's GIL: The Gilectomy 00:32:06 by **Larry Hastings** (2016)
View the list

tedmistonon Hacker News • Recommends

On “Why is Python slow”

See Larry Hastings' talk "Removing Python's GIL: The Gilectomy" from PyCon 2016. link to this video As well as his earlier talk "Python's Infamous GIL". link The GIL is a simple design that provides serious benefit to Python (end user) developers. There are plenty of options for working around this for parallelism, such as the built-in module multiprocessing.
View on Hacker News

pfranzon Hacker News • Recommends

On “CPython internals: A ten-hour codewalk through the Python interpreter (2015)”

Larry Hastings - Removing Python's GIL: The Gilectomy - PyCon 2016 link to this video (I'm pretty sure this is the video I'm thinking of) It's 30m, but worth it if you're interested. Not sure what progress has been made since then.
View on Hacker News

zbentleyon Hacker News • Recommends

On “Questions”

link to this video Or search “gilectomy” on LWN. Or check out stackless etc.; it turns out removing the GIL technically is historically one of the easier parts of removing the GIL entirely. It sounds like your main problem is with python’s GC model. Reference counting doesn’t have to be thread-unsafe, but in scripting/interpreted-ish languages that want their threading story to involve seamless (I.e. no special syntax unless you want it, it’s on you not to blow off your foot) sharing of state between threads at will, like Python and Ruby, a GIL or equivalent is the norm. Sometimes it’s not as intrusive as python’s, but it does seem like a necessary (or at least very likely) implementation pattern for l…
View on Hacker News

santiagobasultoon Hacker News • Recommends

On “Meta pledges Three-Year sponsorship for Python if GIL removal is accepted”

There's a great talk by David Beazley (I don't remember which one) that he basically explains that removing the GIL isn't difficult at all. After all, it's just one lock. The issue is all the libraries and packages that were built around it. It's now been YEARS of building on top of the GIL. So anyways, PEP 703 is a a nice effort, but I doubt we (everyday mortals) can enjoy it. Meta, and big companies with a specialized team might be able to exploit it by making sure their entire stack is GIL-free. EDIT: My bad, the talk is from Larry Hastings: link to this video
View on Hacker News

gshulegaardon Hacker News • Mentions

On “Why is Python slow”

…ido himself mentions the Gilectomy project and it's potential consideration (if it works) for Python 3.6+ 3. So when you say Python leaders declared the GIL a "non-issue", I think you are oversimplifying the actual reality of what removing the GIL means and why leaders (like Guido) have been reluctant to invest resources pursuing. 1 link 2 link to this video 3 link…
View on Hacker News

gshulegaardon Hacker News • Mentions

On “Why is Python slow”

To be fair, the GIL wasn't included because it was a simple threading model (AFAIK). It was included because it was simple to implement and it was/is fast(er) (than removing it)12. If the Gilectomy 2 project succeeds, Guido has mentioned he would consider it for Python3.6+ 3. 1 link 2 link to this video 3 link
View on Hacker News

gshulegaardon Hacker News • Mentions

On “Why is Python slow”

…omy project to try and meet this bar as well as some other requirements currently though 2. But it is currently grappling with the afore-discovered performance issues that come with removing the GIL. Also at PyCon 2016, Guido himself mentions the Gilectomy project and it's potential consideration (if it works) for Python 3.6+ 3. 1 link 2 link to this video 3 link…
View on Hacker News

xapataon Hacker News • Mentions

On “Problems I Have with Python”

…yping has some impressive examples, but in the projects I've worked on has reduced my productivity. Perhaps because data are so often serialized to simple formats or written to databases that discard the best tools of formal typing. Anecdotal evidence, for sure. I've never been bothered by the GIL, but I have benefitted from it 1. 0 link 1 link to this video…
View on Hacker News

gshulegaardon Hacker News • Mentions

On “The multiprocessing module in Python”

…there are some tricks to doing so safely3. But threads of a C extensions library are not necessarily pinned to a single core by the GIL like regular Python byte code. Although many performance oriented libraries like numpy4 forsake multi-threading by default in many cases and rely on parallelization by the user (programmer)5. 1 link 2 link to this video 3 link 4 link 5 link…
View on Hacker News

the_why_of_yon Hacker News • Mentions

On “Python adopts a 12-month release cycle”

In addition to the points other people raised, "simply" removing the GIL by changing the current reference-counting GC to do atomic reference updates will also substantially reduce single threaded performance; there was a PyCon talk about that. link to this video See also Swift for another language whose implementation has performance issues caused by ubiquitous atomic reference counting.
View on Hacker News