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

What Hacker News said

Strong rec gshulegaard · 2017-08 · on “Let's Remove the Global Interpreter Lock”

I feel like the GIL is, at this point, Python's most infamous attribute. For a long time I thought it was also 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): [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 th

Recommends tedmiston · 2016-07 · on “Why is Python slow”

See Larry Hastings' talk "Removing Python's GIL: The Gilectomy" from PyCon 2016. [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.

Recommends pfranz · 2017-03 · on “CPython internals: A ten-hour codewalk through the Python interpreter (2015)”

Larry Hastings - Removing Python's GIL: The Gilectomy - PyCon 2016 [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.

Recommends zbentley · 2018-10 · on “Questions”

[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

Recommends santiagobasulto · 2023-07 · 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: [this video]

Cites gshulegaard · 2016-07 · on “Why is Python slow”

The BDFL (Benevolent Dictator For Life) Guido Von Rossum himself put forth the idea that he would consider a patch removing the GIL in 2007 [1]: > "... I'd welcome a set of patches into Py3k only if the performance for a single-threaded program (and for a multi-threaded but I/O-bound program) does not decrease." Unfortunately, experiments thus far have not succeeded to meet these requirements. There is some work being done by the Gilectomy 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 p

Cites gshulegaard · 2016-07 · 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)[1][2]. If the Gilectomy [2] project succeeds, Guido has mentioned he would consider it for Python3.6+ [3]. [1] [LINK] [2] [this video] [3] [LINK]

Cites gshulegaard · 2016-07 · on “Why is Python slow”

To be fair, the GIL was included (AFAIK) because it was simple to implement. Also, Guido has said (2007) [1] that he would welcome a patch to remove the GIL if...: > "... I'd welcome a set of patches into Py3k only if the performance for a single-threaded program (and for a multi-threaded but I/O-bound program) does not decrease." Unfortunately, experiments thus far have not succeeded to meet these requirements. There is some work being done by the Gilectomy 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 menti