Это видео недоступно.
Сожалеем об этом.

A first look at a faster, no-GIL Python

Поделиться
HTML-код
  • Опубликовано: 31 июл 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: ruclips.net/user/subscription_c...
    FACEBOOK: / infoworld
    TWITTER: / infoworld
    WEBSITE: www.infoworld.com/

Комментарии • 27

  • @SouravBasuRoy
    @SouravBasuRoy 11 месяцев назад +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 7 месяцев назад

      @@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 4 месяца назад +1

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

    • @chintssats12
      @chintssats12 3 месяца назад +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 3 месяца назад +2

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

  • @christopherprobst-ranly6357
    @christopherprobst-ranly6357 11 месяцев назад +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 9 месяцев назад

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

    • @christopherprobst-ranly6357
      @christopherprobst-ranly6357 9 месяцев назад

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

    • @nickthewilde7080
      @nickthewilde7080 9 месяцев назад

      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 9 месяцев назад

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

    • @CharlesMacKay88
      @CharlesMacKay88 8 месяцев назад

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

  • @DanielCardenas1
    @DanielCardenas1 9 месяцев назад +1

    Thanks Serdar! That was very informative! :)

  • @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 2 месяца назад

    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

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

  • @ApexArtistX
    @ApexArtistX 8 месяцев назад

    Need this soon. For custom Gym and RL agents

  • @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 2 месяца назад +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 9 месяцев назад

    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 7 месяцев назад +1

    But without gills, how will pythons breathe underwater?