Комментарии 22
Чтож... Через 20 лет ждем C++ версии 128, Java верссии 114 и Python версии 4 без GIL...:)
А если защищать с помощью блокировок конкретное расширение? Типа если расширение не сообщает, что поддерживает no GIL, то все именно вызовы его функций из Python будут защищены блокировкой, но не глобальной, а отдельной для расширения. Тогда если только один поток использует это расширение (или хотя бы большую часть времени), то производительность всё так же будет в выигрыше. А между тем со временем авторы расширений добавят поддержку.
А смысл? В той нише, где живёт Python, он прекрасно себя чувствует. Заменить JS? Ну так это невозможно по понятным причинам.
Не совсем понял. Как GIL мешает использовать Python в качестве встраиваемого интерпретатора? Прекрасно встраивается же.
Я прекрасно знаю что такое GIL.
Я спросил, что изменится для области применения python, какие возможны новые, грандиозные перспективы, ради которых нужно так радикально менять внутреннюю архитектуру?
Возможность скейлиться по ядрам - самое главное. Условно запустить веб-сервер, который будет использовать все мощности сервера, а не довольствоваться однопоточным asyncio. Сейчас для эмуляции подобного нужно запускать несколько реплик приложения и балансировать между ними. При этом очевидные минусы - это то, что у нас раздельная память у процессов, доп проксирование и т.д.
Также отсутствие GIL позволит не бояться cpu-intensive задач, то есть можно будет просто создать в питоне прям поток, подробить числа в фоне. Сейчас единственный выход - это multiprocessing со своими очевидными минусами.
Я знаю как работают платформы без GIL :-D
Не надо отвечать на вопрос "чем плох GIL и как без него хорошо".
Вопрос - какие именно ниши питон сможет занять, в которых сейчас всё плохо, после изменения GIL? back api .NET/JVM плохо справляются? Выполнение в браузере? Про числодробилки даже не знаю что ответить ))
В каких областях питон может ЗАМЕНИТЬ существующий стек, после вырезки GIL?!
Числодробилки — неудачный пример. Python слишком медленный для вычислительных задач даже если его распараллелить. А если писать расширение на другом языке, то там GIL и не мешает особо.
Все же GIL мешает запускать потоки из питона. Понятно, что всегда можно всегда на си запустить тред, но во-первых это просто сложнее, во-вторых все равно нет возможности иметь доступ к питонячьим объектам - чтобы к ним обратиться нужно захватить GIL. Отсутствие GIL решает эти проблемы. Да, напишем числодробилку на чем-то производительнее (C, Cython, что угодно), но использовать это будет сильно проще.
Числодробилка обычно для расчётов не использует объекты Python, так как они заметно медленнее. А в этом случае можно смело отпустить GIL.
Сам GIL не мешает запускать потоки. И если в каждом из потоков вызывать функции из бинарного модуля, которые отпустили GIL, то работать будут функции одновременно.
Да и если говорить о потоках внутри бинарного модуля, то часто для численных расчётов ничего больше OpenMP и не нужно, а это не такая сложная штука.
Можно и в самом Python распараллеливать вычисления с помощью, например, Numba.
В общем, я не спорю, что без GIL было бы больше возможностей. Я лишь хотел сказать, что числодробилки — это неудачный пример.
Как сказать прекрасно - контейнеры с джанговскими серверами дублируются в несколько воркеров, тк нельзя распараллелить питоновскими средствами. Некоторая простая статистика в мльных расчётах (которая запускается один раз и нет смысла переписывать на си) тоже числодробится в один поток.
В каком смысле "заменить JS"? Если что, у JS тоже есть свой GIL.
Ядер с каждым годом становится всё больше, так что GIL со временем будет большой занозой для фреймворков на python и ruby на многоядерных процессорах. Интересно насколько mimalloc такая панацея? В любом случае питон хуже не станет.
То есть все те проекты для ускорения Питона, которые возникали, в том числе на бабки спонсоров, попросту не обладали такими людьми, как Сэм Гросс? Интересненько.
Удаление GIL из Python: заметки со встречи Python Core и Сэма Гросса