Мигель Гринбе (Miguel Grinberg), автор нескольких книг по Python-фреймворкам SQLAlchemy и Flask, опубликовал результаты тестирования производительности веток CPython с 3.9 по 3.14. Дополнительно аналогичные тесты проведены для Pypy 3.11 (реализация Python с JIT-компилятором), Node.js 24 и Rust 1.90...Подробнее: https://www.opennet.me/opennews/art.shtml?num=64029
Все-таки ускорили питон? Не прошло и десяти лет. А нет, прошло.
> Все-таки ускорили питон? Не прошло и десяти лет. А нет, прошло.Видимо мсье не понимает что это такое в принципе, но обязательно должен высказаться.
> Все-таки ускорили питон? Не прошло и десяти лет. А нет, прошло.На 20%. При отставании от C в 60 тысяч раз. Это успех.
Опустим множитель кило, в 60 раз.
Не в шестьдесят, а в почти полные семьдесят.
Ну и кто там хотел избавиться от GIL? Довольны?)
Само по себе не имеет значения. Если асинхронный код в итоге выиграет, будет неплохо.
Кому неплохо? Представь себе, в Python не все вeб-мakаки на хайлоаде, а в остальных местах async особо и ни нужон
> Кому неплохо? Представь себе, в Python не все вeб-мakаки на хайлоаде, а
> в остальных местах async особо и ни нужонНа локалхосте есть миллион и одна полезная задача, легко решающаяся асинхронным кодом. Только он на треть медленнее в 1 поток я так прикидывал, но если задача параллельная, легко отыгрывается. Ручная возня с запуском тредов ни разу не окупилась, они слишком неоптимальны в итоге.
ага, оптимизации в два раза в мульти-трединге между 3.13 и 3.14 просто показывают насколько весь язык не заточен для мульти-треда и конь не валялся оптимизировать это все. Взять любой мачурный язык, так дай бог если 5% ускорения в вакууме между релизами завозят
Это лишь показывает, насколько питон отвратителен.
>Взять любой мачурный язык, так дай бог если 5% ускорения в вакууме между релизами завозятПотому, что они изначально сделаны хорошо.
Ну если у тебя задача параллельная, где много чего-то ждут чего-то, а потом делают чего-то, то да, а если нет, то сам async становится лишней вознёй, и тем более странным выглядит желание некоторых фанатиков бездумно перетащить в async все библиотеки, думая видимо, что async "эта крута", и не совсем понимая, что это инструмент для довольно чётко очерченного круга задач
Никогда не знаешь, когда она станет параллельной. Сегодня 1 потока достаточно, а завтра ты захочешь 1000 запускать. У меня так было много раз с requests, зачем ждать 300 секунд, если можно управиться за 3? Потом sqlalchemy и так далее, да, такие библиотеки "это крута", и позволяют повысить производительность кода в сотни раз совершенно без затрат и значительных изменений логики.
Это если ты вообще не понимаешь что ты делаешь. Тебе нужно запускать максимум по одному потоку на ядро процессора.
Ээээ... для i\o bound задач?!
Для любых. У тебя есть только N физических ядер. Далее яитаем про thread pool, stealing work и далее. Нет, конечно, когда ре5чь идёт по python то там вообще плевать.
> Это если ты вообще не понимаешь что ты делаешь. Тебе нужно запускать
> максимум по одному потоку на ядро процессора.Нет, мне нужно запускать ничем неограниченное число потоков, пока я получаю ускорение на 1 физическом процессоре (а питон "однопоточный" нужно помнить). И асинхронный код тут замечательно масштабируется.
Ну вот сканирую я определённые данные на диске, что-то с ними делаю. Но ок как-то работает. А потом данных всё больше и больше и больше, да и не на одном диске внезапно, а значит всё можно обрабатывать параллельно. Если запустить пул тредов, где-то обработается быстрее, где-то медленнее, в итоге постоянно процессор простаивает и итоговое время больше, и это ещё мне нужно заботиться о раздаче заданий. С асинхронным кодом раскидал ивент лупы и они молотят на полную, я сразу получаю синхронизацию в точках, где она нужна, и всё остальное меня не заботит.
Больше всего профит при работе с сетью и базами данных как по мне, но в любом случае языки без асинхронных генераторов сегодня вообще не в тему.
Физические ядра тут не помогут, у питона не потоки, а гринтреды, они в рамках системы выглядят как один поток, и существуют не для параллельных вычислений, а для удобной абстракции "подождать ответа от медленного источника данных".
>Физические ядра тут не помогут, у питона не потоки, а гринтредыПроблема не в зелёных потоках, а в gil.
Дело не в самом параллелизме, а в том, что когда у тебя нет вот этого "ждут чего-то", то async тебе ничем не поможет, ведь он сделан именно для того, чтобы утилизировать время простаивания в многопоточном коде. Нет простаивания и/или многопоточного кода? Извольте. Ну и, как уже было сказано выше, вэб-вознёй круг задач, решаемых с помощью python и его экосистемы не ограничивается.
>Ручная возня с запуском тредов ни разу не окупилась, они слишком неоптимальны в итоге.Тем временем, можно взять любой язык с зелёными потоками, хоть ocaml, хоть go, хоть любой другой язык на ваш вкус.
GIL им на хвост наступил.
Очень даже. 3.14 без gil будет побыстрее более ранних версий (за исключением 3.11 наверно) даже в однопоточке. А в многопоточке без gil уж и подавно. Вопрос только когда это все там устаканится, ибо неявных багов там должно быть еще море. 3.14 еще пилить и пилить. Изменение слишком уж кардинальное, впору было бы питон4 называть.
И опять без обратной совместимости, прощайте все батарейки :)
Производительность питона -- последнее что имеет значение на практике. Не удивлён производительности жита, небось, и сравнивали шланговые билды с гццшными?
Производительность программы не может не иметь значения. Это буквально время, оно самый дефицитный ресурс. То, что питонисты считают иначе, много о них говорит. Питон - это не язык создания программ, а клуб по интересам или секта.
Там, где нужна производительность, давно скомпилированный нативный код вызывается. И он освобождает gil. Ты так говоришь, будто на свете только pure-python реализации и всех заставляют ими пользоваться.Да и вон портаж уже переписали на плюсы, сильно эффективнее чёт не стало, зато сопровождение ммм прелесть. А ведь это всего лишь ПМ.
Где нужен перворманс там не питон выбирают. Так что на практике ему достаточно не быть таким дном как руби первой версии.
Куда торопишься, снова суетиться? А жить когда?
> Производительность программы не может не иметь значенияКонечно может. В скриптах производительность не имеет никакого значения.
> Это буквально время, оно самый дефицитный ресурс. То, что питонисты считают иначе, много о них говорит.
Ну давай, решай на компилируемом языке те задачи, для которых спользуется скрипты на коленке. Потом посчитаем, сколько ты угрохал на это время, лол. А заодно и сколько сэкономил быстродействием своей программы. Дефицитный ресурс, ага.
Время _программиста_ дефицитный ресурс.
А cpu time для огромного количества задач не то, чтобы "значения не имеет" - но где-то около.
В 3.14 free threading уже не особо и замедляет. Явный прогресс!
Python лучше всех - доля рынка эта вещь упрямая!
Доля рынка языков для непрограммистов.
Для неОпрограммистов
Миллиарды мух не могут ошибаться...
То, что не могло бы появиться без таких проектов лучше бы и не появлялись.
> Миллиарды мух не могут ошибаться...Годы идут, а опеннетные эксперты все про "миллиарды мух"...
> То, что не могло бы появиться без таких проектов лучше бы и не появлялись.
Ну да, выкидываем все научные рассчеты и ML, чтобы не ломать картину мира опеннетного эксперта.
> все научные рассчетыпод капотом имеют библиотеки на C и Fortran, используя сабжа только как интерфейс для ввода-вывода данных. Не в укор сабжу - многие другие научные проекты поступают так же.
В бэкенде что-то не особо.
Слава богу, на спад идёт. Питон плохо приживается
А что кстати мешает питону официально перейти на PyPy?
> А что кстати мешает питону официально перейти на PyPy?То, что он хорош только в попугаеметрах.
А чем плох в реальных задачах?
> А чем плох в реальных задачах?Все минусы жита, плохая поддержка в существующем коде, потенциальные баги.
Поддержка и баги это следствие малой пользовательской базы и малого количества разработчиков. А вот минусы jit в студию.
> Поддержка и баги это следствие малой пользовательской базы и малого количества разработчиков.
> А вот минусы jit в студию.
Номер объекта: SCP-JITКласс объекта: Евклид
Особые условия содержания:
SCP-JIT должен быть изолирован в камере с имитацией выполнения (выделенный набор виртуальных машин 7). Ни одна производственная система не должна выполнять код, сгенерированный SCP-JIT, без одобрения 3-го уровня.
Специальный агент мониторинга (Process Sentinel) должен отслеживать использование процессора, памяти и памяти исполняемых файлов на хосте. Любые необъяснимые скачки времени компиляции, выделения памяти или создания исполняемых страниц немедленно инициируют карантин и откат к снимку AOT.
Трассировки профилирования и сегменты машинного кода, созданные SCP-JIT, должны храниться в архиве WORM и анализироваться на предмет недетерминированного поведения. Все тесты должны включать измерения при холодном старте и повторные испытания для выявления отклонений. Для сценариев развертывания, требующих детерминизма или низкой задержки, SCP-JIT запрещён; вместо этого будут использоваться артефакты AOT или изолированная эмуляция.Описание:
SCP-JIT представляет собой адаптивный генератор кода, преобразующий промежуточный байт-код в машинные инструкции во время выполнения. При наблюдении он демонстрирует полезное эмерджентное поведение — значительное увеличение пропускной способности для длительных процессов — наряду с рядом опасных побочных эффектов, которые, если их не устранить, снижают стабильность работы.Задокументированные аномалии / Основные недостатки:
Задержка запуска и прогрев
SCP-JIT требует циклов прогрева для отслеживания горячих путей перед созданием оптимизированного кода. Начальное выполнение медленнее; кратковременные или однократные процессы никогда не достигают оптимизированного устойчивого состояния и испытывают общую деградацию.
Увеличенный объём памяти
Страницы машинного кода, метаданные и буферы профилирования времени выполнения накапливаются, раздувая рабочие наборы. В условиях ограничений это приводит к подкачке, перегрузке сборщика мусора и повышению частоты сбоев.
Нагрузка на процессор и электропитание
Компиляция происходит в штатном режиме, потребляя циклы процессора и электроэнергию. Во время фаз интенсивной оптимизации происходит падение производительности и превышение лимитов на тепло/энергию.
Недетерминированная производительность
Решения по оптимизации принимаются на основе профилей времени выполнения; идентичные входные данные в разных запусках могут давать разные характеристики производительности, что затрудняет бенчмаркинг, планирование ресурсов и воспроизведение инцидентов.
Сложность отладки и наблюдения
Динамически генерируемый код и агрессивные оптимизации (встраивание, деоптимизация) скрывают стеки вызовов и изменяют поведение при проверке. Стандартные отладчики и профилировщики могут создавать ложные следы.
Расширение области безопасности
SCP-JIT выделяет области памяти для записи и исполнения и выполняет динамическую эмиссию кода — практики, которые увеличивают поверхность атаки и требуют усиленных политик и мер по снижению риска (аудит исполняемой памяти, целостность потока управления).
Пики задержки и джиттер
Фоновая компиляция, перекомпиляция или деоптимизация «на лету» могут приводить к периодическим всплескам задержки, неподходящим для сервисов реального времени или с низкой задержкой.
Ограничения развертывания и переносимости
Некоторые операционные среды запрещают генерацию кода во время выполнения или не имеют целевых бэкендов, что препятствует использованию SCP-JIT. Упаковка и верификация на нескольких архитектурах требуют дополнительных инженерных усилий.
Сложность настройки и предсказуемости
Правильная настройка пороговых значений, уровней компиляции и взаимодействия с GC требует экспертных знаний. Неправильная настройка может ухудшить производительность, а не улучшить ее.
Дополнение — Протоколы смягчения:
Используйте многоуровневую компиляцию и AOT с профилированием для холодных путей; ограничьте агрессивную оптимизацию фоновыми потоками; ограничьте объем памяти, используемой для сгенерированного кода; включите квоты компиляции и пороговые значения пауз компиляции; требуйте зашифрованного хранилища с проверкой целостности для выпущенного кода; Внедрение детерминированных тестовых программ для бенчмаркинга.
Уведомление от инженеров сайта: Используйте SCP-JIT только в тех случаях, когда длительные рабочие нагрузки и контролируемые среды оправдывают риски. Для кратковременных задач, систем реального времени или высокозащищённых песочниц предпочтительнее AOT или интерпретируемое выполнение.
Выдержка из журнала содержания (отредактировано):
«Процедура 7.2 вызвана после скачка загрузки ЦП на 120%, связанного с событием перекомпиляции «на лету». Карантин предотвратил каскадный сбой. Рекомендация: ограничить приоритет потока JIT-компилятора». — Ведущий инженер, Отдел стабильности выполнения
Конец файла.
кстати, целиком правда
Жрет дофига памяти (Которая - в отличие от CPU - не то, чтобы "хорошо разделяемый" ресурс) и "не дает"\"дает незначительную" прибавку к производительности - и задачи у тебя сильно не все cpu bound, и не весь тот cpu на hot path обрабатывается pure python кодом...
Ограниченная область применения
Сделано не ими.
И PyPy, решая ту же проблему, не нуждается во всяких LLVM.
Потому, что между cpython и pypy есть отличия.
Если бы команды объединили усилмя, различия бы устранили.
Ну то есть ничего особо не поменялось.)
Я на графиках на другое обратил внимание. При прочих равных, производительность разных Питонов на MacOS несколько выше, чем на Linux. Darwin же основан на микроядре Mach? Значит, расхожее мнение о худшей производительности микроядерных ОС - миф?
Лично мне, это добавило надежд в отношении производительности Hurd.
Странный вывод.
Автор тестил на том что было, а было у него 13th Gen Intel(R) Core(TM) i5-1340P (он об этом написал в комментах своего блога) и Apple M2. Отсюда и разница.
Дарвин, конечно, сделан (когда-то давно) на ядре Mach, да только на том ядре крутится один-единственный процесс "система", внутри которой обычное юникс-ядро, то есть микроядерный ipc не используется.Но в принципе ты прав, Hurd на современном железе совсем не медленный.
Традиционное фибоначчи-в-вакууме, ага.
Нет бы - ну не знаю - какую fastapi\django'у по контейнерам с разными версиями интерпретатора подсобрать-да-нагрузить...
Чтобы что? Чтобы ловить сайд эффекты производительности docker/podman, fastapi, django и какого-нибудь gunicorn? А потом делать неверные выводы?
В том то и суть, чтобы все это исключить.
> Чтобы что? Чтобы ловить сайд эффекты производительности docker/podman, fastapi, django
> и какого-нибудь gunicorn? А потом делать неверные выводы?
> В том то и суть, чтобы все это исключить.Ну меня очень радуют "верные выводы" сделанные в тестах того же pypy - но очень огорчает несовпадение этих выводов с реальностью примерно во всех наблюдаемых вариантах практического использования.
Стандарт и жЫд не сильно отличаются, а кто-то мне втирал за скорость :)
> автор нескольких книг по Python-фреймворкам SQLAlchemy и Flask,
> опубликовал результаты тестирования...очередного удвоения надоев на тему того как именно питон не тормозит :)
Больше всего мне здесь нравится график Rust. Которого почти не видно.
> Rust обогнали CPython 3.14 в первом тесте в ... 69.82 раз, а во втором тесте в ... 36.15 разЭто удивительно - компилируемая программа оказалась быстрее интерпретируемого скрипта.
Уровень опеннетсперктизы.
Питон тоже компилируется.
> Уровень опеннетсперктизы.
> Питон тоже компилируется.Так речь о скрипте для cpython. Когда питон компилируется (тот же cython), там производительность 1 в 1 с си.
> (глубокая рекурсия)обычно заканчивается переполнением стека.
В нормальных языках хвостовая рекурсия оптимизируется начиная с первого релизного компилятора/интерпретатора.
Зачем-то питон форсят в веб, он там не нужон, пых лучше же намного. А всякое ML и прочее - ну это вообще неинтересная ниша.
Истину глаголишь. Самый лучший веб это php или perl.
> Истину глаголишь. Самый лучший веб это php или perl.Нет, это битрикс.
Хуже Perl'а только Brainfuck. Это write-only язык. Хорошо что он помер.
То, что PyPy быстрее Node.js, приятно удивило. Хотя, казалось бы, размеры пользовательской базы и количество разработчиков несравнимы.
Ну он раньше появился, аж в 2002 году. И сишка в rpython быстрее плюсов в нодовском V8.
micropython всё равно вне конкуренции. Хотя, казалось бы, у него ресурсов меньше на оптимизацию.
Удивительно, насколько отвратительные языки набрали популярность.
>Pypy, Node.js и Rust обогнали CPython 3.14 в первом тесте в 4.93, 4.88 и 69.82 разТо есть современная версия питона с кучей оптимизаций тормознее в семьдесят раз по сравнению с нативной версии с ручным управлением памятью. Интересно, а насколько же тормозными были первые версии гвидобейсика?
В восьмидесятых(а то и раньше) уже были простые (без ручного управления памятью) компилируемые типобезопасные языки. То есть написание больших(по количеству строк кода) уже на момент появления питоном портилось, ведь ошибки всплывали во время выполнения.
Если брать небольшие скрипты, то на тот момент уже были скриптовые языки, и питон не был революцией и в этом плане.
А если добавить к этому, что языки появившиеся позже успели получить гораздо более производительные реализации, то становится решительно непонятно, зачем этот питон вообще нужен.
Однако, кроме скорости исполнения, которую крайне медленно, но всё же увеличивают, у питона остаётся второй недостаток, которые старательно игнорируют: гораздо большее потребление памяти. И с этим уже ничего больше не сделать, так как этот изъян врождённый. Ну не сможет динамически типизированный язык быть столь же компактым, как и статически типизированный.
А теперь самый важный недостаток питона, нулевой: кому-то в голову приходит писать на питоне не просто скрипты на несколько десятков строк, а полноценные большие программы. Какие-то из них питон убил своей обратной несовместимостью, ну а те, что дошли до наших дней продолжают тормозить.
Пока что питон в десятки раз меньше го памяти потребляет в рантайме на ровно тех же задачах. К слову о "компилируемых" языках. И эффективно шарит её. Смотрю на тебя раст.