Has the Python GIL been slain Article

[MagicalAzareal]

https://hackernoon.com/has-the-python-gil-been-slain-9440d28fa93d
I'm not quite sure the best place to throw bits of news like this (Programming? RSS Feed?), but this seems pretty cool. It looks like it could improve CPython's performance by quite a bit.

If I recall though, many libraries like NumPy, etc. use C to release the GIL momentarily to do their calculations, so it might not change *too* much in some situations.

 

[rafalp]

The GIL is something that people not programming in Python point as fatal flaw and everyone programming in Python doesn't care about (because it only kicks in in limited number of cases) or sidesteps altogether.

Awesome things are happening when it comes to async programming. You can swap default event loop for uvloop which gives you awesome performance, and increasing number of Python libs are adopting async support.

GIL behavior used to be quite simple and predictable - run 100 bytecodes for thread A. Serialize and store thread A state somewhere, deserialize thread B state, run 100 bytecodes, rinse and repeat. Today GIL is released to next thread when you try doing IO (which rarely takes less time than switching to next thread and running 100 bytecodes), bytecode produced from Python code is more efficient and CPython itself has gotten faster, with 3.7 becoming faster than 2.7 for common tasks like webapps parsing strings and talking to database.

All of this adds up to python performance not being a problem for many users.