A first look at a faster, no-GIL Python

CPython's Global Interpreter Lock, or GIL, has long prevented it from being a truly parallel, multicore language. A new proposal, PEP 703, describes a roadmap to a new design for CPython that can use multithreading to properly unlock parallelism. Watch in this video as we use a prototype build of the "no-GIL" edition of Python to demonstrate how much faster code can be if this proposal takes off.
Read more here about PEP 703 and what it promises: www.infoworld.com/article/370...
-----------------------------­---
SUBSCRIBE: kzbin.info_c...
FACEBOOK: / infoworld
TWITTER: / infoworld
WEBSITE: www.infoworld.com/

[@SouravBasuRoy]

this will make python #1 permanently, in the list of top programming languages

[@yarmgl1613]

the interpreter is still slow, and it's weakly typed

[@DhruvRed]

@@yarmgl1613 That is no longer the issue with language but with the programmer, as types are available in python and programmer can and should mention types with variables and function return types

[@atomicgray]

What lol python is strongly typed, what you are looking for is dynamically typed

[@chintssats12]

I second that @SouravBasuRoy. With the faster python project no doubt Python will hold the throne.

[@niks660097]

@@yarmgl1613 technically C is also weakly typed, since you can use pointers to keep any type of data, Dynamic type vs static type is different than weakly vs strongly typed, RUST is strongly typed, C/C++/Java/Golang/C# all are weakly typed but static typed.

[@ciberman]

I am a C# guy. I used Python for my degree thesis and my only concern with the language was the lack of a built in way of using class events (EventDispatcher or similar) and the GIL limitation for multithreading math heavy computation. I don't normally use python, but I am really glad that the GIL is being refactored.

[@christopherprobst-ranly6357]

It has no negative effect on async, its something entirely different. Even better, async will benefit as we can finally have truly multicore servers without using multiple processes.

[@maciejurbanski6146]

except asyncio loop has to run in single thread, and most asyncio stuff is marked as not-thread-safe

[@christopherprobst-ranly6357]

@@maciejurbanski6146nah, you would run one event Loop per thread.

[@nickthewilde7080]

If you're talking about asyncio, unless the core developers explicitly state they have plans for supporting asyncio, chances are they wont adapt that library. Going from context-switching to paralellism will break most asynchronous programs

[@christopherprobst-ranly6357]

@@nickthewilde7080you Don‘t Need Support. Create a new eventloop per thread/subinterpreter. You will get Speed up.

[@CharlesMacKay88]

@@nickthewilde7080 asyncio is part of the standard python library. what do you mean the core developers wont support it?

[@Oodle-ox2vf]

Sounds promising, will need to introduced carefully. Can't wait to try it.

[@yash1152]

0:51 > _"use threads to wait on network io or user io"_ good 4:15 approach used by the new no-GIL

[@DanielCardenas1]

Thanks Serdar! That was very informative! :)

[@vihaanthora8089]

Thanks for the video, it summarized the no-gil version really well! I would love to see a video that would dive deeper in how the reference counting has changed in this version and why it is thread safe. Cheers!

[@InfoWorld]

Yes, I plan to do a good deal more video material about the changes in no-gil as they get rolled out in official Python releases. -Serdar

[@ThankYouESM]

During 2010, a friend of mine implemented a workaround way for Python to piggy-back on C to get the best of both worlds. He hated having to write in C, but... loved writing in Python... then years later created a way to get Python to write C. Sadly enough... he never shared that code with anybody.

[@ApexArtistX]

Need this soon. For custom Gym and RL agents

[@pietraderdetective8953]

What kind of performance improvement can we expect? This coupled with Cython should be a speed demon?

[@InfoWorld]

The performance increases are going to depend entirely on the workload in question, but it's clear one of the big benefits is being able to cleanly parallelize workloads across CPU cores using the existing threading interfaces. -Serdar

[@olejrgenbrnner4708]

Yes, AFAIK regular single-threaded code will become *slower*

[@gvozdyara9563]

Calling Cython or other c-library releases the GIL, if I’m not mistaken. So calling cython makes Python code multicore-running.

[@robertlawson4295]

But then, gliding over the horizon ... oh no, it's Mojo (a superset of Python) to the rescue. Dum Dum (ominous musical notes). To be continued ... maybe.

[@shaurz]

But without gills, how will pythons breathe underwater?

[@wishabhilash]

Through its skin.