A first look at a faster, no-GIL Python

Поділитися
Вставка
  • Опубліковано 10 лип 2024
  • 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: ua-cam.com/users/subscription_c...
    FACEBOOK: / infoworld
    TWITTER: / infoworld
    WEBSITE: www.infoworld.com/
  • Наука та технологія

КОМЕНТАРІ • 27

  • @SouravBasuRoy
    @SouravBasuRoy 10 місяців тому +17

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

    • @yarmgl1613
      @yarmgl1613 8 місяців тому

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

    • @DhruvRed
      @DhruvRed 6 місяців тому

      @@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
      @atomicgray 3 місяці тому +1

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

    • @chintssats12
      @chintssats12 2 місяці тому +1

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

    • @niks660097
      @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.

  • @Oodle-ox2vf
    @Oodle-ox2vf 2 місяці тому +1

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

  • @DanielCardenas1
    @DanielCardenas1 9 місяців тому +1

    Thanks Serdar! That was very informative! :)

  • @christopherprobst-ranly6357
    @christopherprobst-ranly6357 10 місяців тому +9

    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
      @maciejurbanski6146 8 місяців тому

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

    • @christopherprobst-ranly6357
      @christopherprobst-ranly6357 8 місяців тому

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

    • @nickthewilde7080
      @nickthewilde7080 8 місяців тому

      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
      @christopherprobst-ranly6357 8 місяців тому

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

    • @CharlesMacKay88
      @CharlesMacKay88 7 місяців тому

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

  • @yash1152
    @yash1152 11 місяців тому +3

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

  • @ciberman
    @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.

  • @vihaanthora8089
    @vihaanthora8089 9 місяців тому +1

    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
      @InfoWorld  9 місяців тому

      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

  • @ApexArtistX
    @ApexArtistX 7 місяців тому

    Need this soon. For custom Gym and RL agents

  • @ThankYouESM
    @ThankYouESM 7 місяців тому +1

    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.

  • @pietraderdetective8953
    @pietraderdetective8953 11 місяців тому +2

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

    • @InfoWorld
      @InfoWorld  11 місяців тому +4

      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
      @olejrgenbrnner4708 5 місяців тому +1

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

    • @gvozdyara9563
      @gvozdyara9563 Місяць тому +1

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

  • @robertlawson4295
    @robertlawson4295 8 місяців тому

    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
    @shaurz 6 місяців тому +1

    But without gills, how will pythons breathe underwater?