No video

Python 3.13's new JIT and no-GIL modes

Python 3.13 provides early access to some groundbreaking new features in CPython, the default Python interpreter. A new JIT can enable speedups in "hot spots" in Python code, by selectively replacing generic instructions with specialized versions and by using a new second-stage bytecode - without having to rewrite any existing Python code. And the new "free-threaded", or "no-GIL" build, lets Python threads run with true parallelism.
However, none of these features are enabled by default yet. To use them, you need to build a custom edition of the Python interpreter. In this video, we've done just that, and we show some examples of where both of these new features add real value to Python.
Twitter: @syegulalp
LinkedIn: / serdar-yegulalp-136a483
-----------------------------­---
SUBSCRIBE: kzread.info_c...
FACEBOOK: / infoworld
TWITTER: / infoworld
WEBSITE: www.infoworld.com/

Пікірлер: 9

  • @sdmagic
    @sdmagic2 ай бұрын

    Very nicely done.

  • @OmarHashimOAD
    @OmarHashimOAD2 ай бұрын

    I enjoy your content; keep up the great work!

  • @felixfourcolor
    @felixfourcolorАй бұрын

    I believe Fedora 41 will ship Python with the JIT, but disabled by default (can be turned on via command line argument). I don't think any distro will ship free-threading though.

  • @InfoWorld

    @InfoWorld

    Ай бұрын

    That's useful to know. 3.13 beta 2 is shipping with an experimental version of free-threading enabled for Mac users during the installation process, but so far that's the only precompiled version being shipped by Python.org right now. For the time being the rest of us will have to compiled it by hand. -Serdar

  • @alexandermorgan5869
    @alexandermorgan58692 ай бұрын

    Great video! Are there any instructions on how to build these two different versions of python 3.13?

  • @InfoWorld

    @InfoWorld

    Ай бұрын

    I actually have plans for a future video where I demonstrate the compilation process on Windows! Stay tuned. -Serdar

  • @teawithoutdonuts31
    @teawithoutdonuts31Ай бұрын

    The question I eant answered is how will this affect ASGI and WSGI web frameworks.

  • @benshapiro9731

    @benshapiro9731

    Ай бұрын

    My best guess based on experience with FastAPI: the way fast api runs its route handler funcs is if the func is a coroutine (async def) and thus can pause execution during await calls, then it is run on the main thread. If it is a blocking function (def) then it is delegated to the underlying threadpoolexecutor via something like asyncio.to-thread. In my experience, a lot of production code uses just normal functions as opposed to Coroutines for the route handlers due to the relatively recent introduction of async mechanics into the language. If running the no Gil python really has no effect on single threaded code, then at worst this change will have no effect and at best it will give asgi frameworks that work similarly to fastapi a huge speed boost (since those blocking route handler funcs can be executed truly in parallel via the thread pool executor). As far as I know the current best practice is to put non blocking io into async functions and cpu bound tasks into regular functions. Even though Asyncio event loop executes coroutines on the same thread as the event loop, the fact that coroutines are a much lower cost abstraction than threads means that this execution model is faster than using a thread pool. However, the removal of the Gil could change that if the numbers and benchmarks start telling a different story. This may necessitate some internal changes to various asgi frameworks to delegate more coroutines to thread pools as opposed to running them on the main thread. But if your route handler funcs are just regular functions, then out of the box this should yield a major speed increase.

  • @jaimel8219

    @jaimel8219

    19 күн бұрын

    The culprit will be the 3rd party libraries partially unmaintained that most web apps depend on. GIL enabled tons of thread-unsafe code to be written.