Всем привет! Сегодня хочу поделиться с вами хорошими новостями, которые связаны с производительностью python в грядущем релизе 3.11 и то, что нас ожидает в будущем!
Достаточно долгое время существенных ускорений в CPython не наблюдалось, были определённые улучшения в некоторых последних версиях, но особо на итоговую производительность, даже в специальных задачах это не cлишком сильно влияло, не говоря о задачах общего назначения, которые и составляют основную работу.
Всё начало меняться недавно, когда объявили о работе над проектом faster СPython. Первая подготовительная работа уже началась в 3.10, а первые реальные улучшения должны были быть показаны в 3.11, что и произошло недавно при выходе новой альфа версии python 3.11.
Давайте, наконец, перейдём к самому главному и начнём сразу с основного тезиса, что нас ожидает в будущем:
Python 3.11 is up to 10-60% faster than Python 3.10. On average, we measured a 1.22x speedup on the standard benchmark suite.
This project focuses on two major areas in Python: faster startup and faster runtime.
Как мы видим, в грядущем релизе нас ожидает значительное ускорение производительности python! Конечно, в определённых задачах мы не увидим существенного различия(не берём в расчёт задачи, где основной bottleneck составляет i/o нагрузка), но сам факт того, что заявляются такие большие значения не может не радовать, и в особо узких местах(в определённых задачах) мы получим очень хороший прирост производительности, но уже на данный момент точно ясно одно, что общая итоговая производительность приложений вырастет для всех! А если у вас большой парк серверов и сервисов написанных на Python, которые там работают, то улучшение даже на 10 процентов вы заметите, не говоря уже о больших значениях, которые также заявляются.
Предлагаю на данном моменте ознакомиться с ростом производительности в синтетических бэнчмарках на текущий момент: клик
Почему это удалось? Что было сделано?
1) Faster Runtime
Была проведена работа с оптимизацией фреймов, которые создаются при вызове функций. А в большей части пользовательского кода, объекты фрейма, при вызове функций, теперь не создаются вовсе, что привело к итоговому приросту производительности на 3-7 процентов.
Python frames are created whenever Python calls a Python function. This frame holds execution information. The following are new frame optimizations:
Streamlined the frame creation process.
Avoided memory allocation by generously re-using frame space on the C stack.
Streamlined the internal frame struct to contain only essential information. Frames previously held extra debugging and memory management information.
Old-style frame objects are now created only when required by debuggers. For most user code, no frame objects are created at all. As a result, nearly all Python functions calls have sped up significantly. We measured a 3-7% speedup in pyperformance.
2) Inlined Python function calls
Данная оптимизация позволяет полностью избежать вызова оценивающей функции С для интерпретации кода функций python, которая ранее вызывалась всегда. Для рекурсивных функций данная оптимизация позволила получить ускорение в 1.7 раза, а в общей производительности это улучшение принесло 1-3%.
During a Python function call, Python will call an evaluating C function to interpret that function’s code. This effectively limits pure Python recursion to what’s safe for the C stack.
In 3.11, when CPython detects Python code calling another Python function, it sets up a new frame, and “jumps” to the new code inside the new frame. This avoids calling the C interpreting function altogether.
Most Python function calls now consume no C stack space. This speeds up most of such calls. In simple recursive functions like fibonacci or factorial, a 1.7x speedup was observed. This also means recursive functions can recurse significantly deeper (if the user increases the recursion limit). We measured a 1-3% improvement in pyperforman
И теперь самое главное!
3) Specializing Adaptive Interpreter
Это основная и ключевая часть faster CPython и причина почему python стал настолько быстрее. Идеи и решения, которые заложены в данной части, открывают новые возможности в росте производительности python.
Общая идея заключается в том, что несмотря на то, что python является динамическим языком, в большинстве программ есть области, в которых объекты и типы изменяются крайне редко, данная концепция известна как стабильность типов, и теперь во время выполнения python ищет такие места и заменяет операции на более специализированные. Это также приводит к ещё одной концепции, называемой встроенным кэшированием, теперь Python кэширует результаты ресурсоемких операций непосредственно в байт-коде.
Предлагаю самим ознакомиться с полным текстом, так как данная концепция крайне важна и является новой вехой в развитии python.
PEP 659 is one of the key parts of the faster CPython project. The general idea is that while Python is a dynamic language, most code has regions where objects and types rarely change. This concept is known as type stability.
At runtime, Python will try to look for common patterns and type stability in the executing code. Python will then replace the current operation with a more specialized one. This specialized operation uses fast paths available only to those use cases/types, which generally outperform their generic counterparts. This also brings in another concept called inline caching, where Python caches the results of expensive operations directly in the bytecode.
The specializer will also combine certain common instruction pairs into one superinstruction. This reduces the overhead during execution.
Python will only specialize when it sees code that is “hot” (executed multiple times). This prevents Python from wasting time for run-once code. Python can also de-specialize when code is too dynamic or when the use changes. Specialization is attempted periodically, and specialization attempts are not too expensive. This allows specialization to adapt to new circumstances.
Так же добавили ещё дополнительных оптимизаций, которые являются не такими важными, но тоже ускоряют производительность в определённых местах. Наиболее важными, на мой взгляд, являются следующие:
Objects now require less memory due to lazily created object namespaces. Their namespace dictionaries now also share keys more freely.
A more concise representation of exceptions in the interpreter reduced the time required for catching an exception by about 10%.
“Zero-cost” exceptions are implemented. The cost of try statements is almost eliminated when no exception is raised.
re’s regular expression matching engine has been partially refactored, and now uses computed gotos (or “threaded code”) on supported platforms. As a result, Python 3.11 executes the pyperformance regular expression benchmarks up to 10% faster than Python 3.10.
Почему это стало возможным?
Несмотря на то, что ещё недавно основные разработчики не намерены были ускорять CPython, так как считали, что текущей производительности достаточно для большинства задач и важнее развивать функционал языка, а в случае чего у нас есть Сython/PyPy/Numba/mypyc, расширения написанные на С и т.д.. То на данный момент всё поменялось.
Самое главное - это финансирование Microsoft, которое позволило работать на постоянной основе над проектом.
Найм на постоянную работу над CPython разработчика Марка Шэннона, ранее штатных разработчиков у CPython не было и язык развивался только благодаря сообществу и внеурочной работе её членов.
Использование наработок из HotPy, HotPy2.
Большой запрос среди сообщества на ускорение производительности python.
Конкуренция с другими языками, на которые приходилось мигрировать в связи с большой нагрузкой в определённых сервисах и "горячих местах".
Тренд на ускорение производительности и оптимизации в языках. На данный момент большое количество языков постоянно заявляют об улучшениях производительности и о готовности работать в данном направлении.
И, конечно же, желание основных разработчиков этим заниматься.
Какие изменения нас ждут в будущем? И какая конечная цель?
Общая цель — это ускорение CPython в 5 раз в ближайшие 4 года! Планируется это сделать в 4 отдельных этапа, каждый из которых увеличивает скорость CPython на 50 процентов.
Планируется улучшать интерпретатор, улучшать работу с памятью и самое главное добавить JIT компилятор, и далее постепенно его улучшать для создания превосходного машинного кода.
Конечно же будет сохранение обратной совместимости, что является немаловажной идеологией python на данный момент, после сложного перехода с python 2 на python 3.
С подробным планом faster CPython советую ознакомиться тут
И в конце предлагаю посмотреть никем особо не замеченное видео о том, как будет ускоряться python в будущем, почему это происходит, какие изменения нас ждут и какие новые концепции появятся!
Источники:
Комментарии (31)
funca
20.04.2022 17:38+4Самое главное это финансирование Microsoft, которое позволило работать на постоянно основе над проектом.
Общая цель — это ускорение CPython в 5 раз в ближайшие 4 года! Планируется это сделать в 4 отдельных этапа, каждый из которых увеличивает скорость CPython на 50 процентов.
Предыдущая попытка 13 лет тому назад ускорить cpython в 5 раз закончилась почти ни чем https://peps.python.org/pep-3146/ . Вопреки стараниям команды Unladen Swallow из Google, Гвидо решил не усложнять реализацию разными jit'ами (а может просто побоялся потерять контроль?) В прочем, идеи не пропали даром и у нас (них) теперь есть быстрый JavaScript.
Надеюсь, что у Microsoft в этот раз все получится и прирост производительности окажется достойным не только под Windows,)
Revertis
21.04.2022 00:27-5Ровно 15 грубых ошибок отправлены в личку. Автор, может не надо так?
Anisov Автор
21.04.2022 00:49+2Спасибо за бдительность, пропущенные буквы, лишние пробелы и запятые поправлены, не заметил данные опечатки при финальном прочтении материала.
Revertis
21.04.2022 00:53-12Там большая часть - несогласованные падежи и -ться/-тся. Стыдно должно быть!
Anisov Автор
21.04.2022 01:10+1В паре мест не заметил, в следующий раз буду повнимательней на этот счет и буду проверять лучше, текст не маленький, а проверяющего нет, в остальных таких же местах всё было верно и корректно(например, -ться/-тся было в двух местах из всего текста написано не верно, а не повально). Как-никак это техническая тема, а не сочинение по русскому языку, давайте комментарии оставлять лучше по существу и по теме, а остальное лучше в личку, чтобы не захламлять ненужными комментариями пост. Спасибо!
raven19
21.04.2022 10:00+1Как-никак это техническая тема, а не сочинение по русскому языку,
Но в русском языке есть правила, которые должны выполняться, коль скоро Вы его используете. И они ничем не хуже, чем правила языков программирования, которые Вы описываете или, может быть, даже используете. Более того, могу открыть Вам совсем маленький "секрет": есть программы, которые могут проверять Ваш текст на "русском" языке. Более того, большую часть ошибок из Вашей статьи они бы "выделили"! Аминь!
Anisov Автор
21.04.2022 11:18+1Даже многие писатели пользуются и пользовались услугами по вычитке и корректировке текстов, т.к. допускали ошибки. Спасибо за секрет, но увы, не все опечатки они видят, например, вместо предлога "с", был написан случайно предлог "в" или опечатка в окончание слова, но слово читается и так и так верно(пропущена одна буква). Такого рода ошибки они не замечают, как и запятые в сложны местах или оборотах, а часть текста я дописал прямо здесь, в редакторе, не предполагая, что пропущенная запятая или тире вызовет столько комментов, для меня всегда важнее была смысловая часть)
raven19
21.04.2022 12:15-3Ну, блин, до писателя Вам, как до Китая... Ну и кто мешает воспользоваться услугами "по вычитке и корректировке тестов "? Религия не позволяет? А ещё Вам не грех узнать, что программы могут проверять не только орфографию (тот же MS Word), но и грамматику (синтаксис - это чтоб понятнее было), и они смогли бы разобраться со всеми Вашими предлогами, тем более, что Ваши предложения попроще, чем у Льва Толстого.
Когда видишь не отдельные опечатки, а текст с ошибками практически в каждом абзаце (слава богу, что не в каждом предложении), то уж точно трудно сосредоточиться на "смысловой" части! Более того, возникает вопрос: "Если автор так относится к правилам русского языка, может ли он рассказать что либо ценное о языке программирования, который описывает? Может быть его познания в этой области соответствующие?.."
Правда, вынужден признать, что Вы поступили "хитро", вставив куски на англицком в статью на русском. Обычно правилом хорошего тона бывает перевод того, что приведено на языке, отличном от языка статьи (не обязательно дословный и литературный).
Я понимаю, что для большинства читателей Хабра не составляет труда читать оригинальный текст (я не исключение), но это всего лишь "правило хорошего тона", так же, как и письмо без ошибок!.
Честно говоря, не понимаю, почему можно так неуважительно относиться к будущим читателям Вашего опуса и не удосужиться элементарно проверить хотя бы с помощью какого-нибудь "спел-чекера"?
Обычно авторы на замечания об ошибках (желательно, конечно, не в комментариях - тут я готов с Вами полностью согласиться) благодарят и "молча" исправляют! Дискутировать на эту тему, высказывать своё "фи..", оправдываясь смысловой частью, как-то не комильфо!
tarekd
21.04.2022 12:33+4Почему человек, не являющийся профессиональным писателем должен это делать? Такие как Вы отбивают желание писать какие-либо статьи на Хабре.
Есть функция репорта ошибок, почему бы молча не указать автору на недостатки, он же не отказывается их исправить. Если прям топите за грамматику, предложите в личку свои услуги по вычитке на бесплатной основе.
Сколько читаю статьи на зарубежных ресурсах, клали там все на грамматику и ошибки. И не видел комментариев об этом.
Лучше бы дельные комментарии давали по сути написанного.
raven19
21.04.2022 13:08-1Почему человек, не являющийся профессиональным писателем должен это делать?
Что делать? Проверить каким-нибудь спел-чекером свою писанину? Если Вы "не въехали" в мой комментарий, попробуйте перечитать его ещё раз или попросите кого-нибудь более "внимательного" растолковать Вам его смысл...
Если прям топите за грамматику, предложите в личку свои услуги по вычитке на бесплатной основе.
Именно это я и сделал до своих комментариев. Отправил автору кучу исправлений, которые были уже дополнением к тому, что отправил https://habr.com/ru/post/662087/comments/#comment_24284301 до меня. Мы ни разу не пересеклись, как это ни странно!!! А то, что он до меня начал с автором опуса обсуждать эту тему в комментариях, так все вопросы не ко мне...
Просто сегодня какой-то день неправильный: читаю третью статью на Хабре, а там в почти в каждом абзаце ошибки во всех трех, глаз режет...
Такие как Вы отбивают желание писать какие-либо статьи на Хабре.
А сколько статей Вы уже тут написали? Может просто, Вам не о чем сказать? И надо не "желать", а писать, если есть, что сказать...
Лучше бы дельные комментарии давали по сути написанного.
Так по сути там и комментировать-то нечего. Всё на англицком дословно (и без ошибок) сформулировано. Автор пытается "пересказать" то, что написали до него. Только вот сейчас пересмотрел заново и не нашел ссылок на источник/источники, откуда эти цитаты!
Anisov Автор
21.04.2022 13:21+3только вот сейчас пересмотрел заново и не нашел ссылок на источник/источники, откуда эти цитаты!
Видимо, вы даже прочесть нормально не удосужились, первая ссылка в источниках... Это не гайд, а новость основная на том что будет, естественно я пользуюсь оригиналом, дабы не искажать смысл, а в тех местах где нужно и что нужно я перевёл и написал своими словами, как посчитал нужным. Я уже получил много благодарностей в личку о том, что статья очень хорошо написана, причём от популярных людей в сообществе. Все поняли, что вы самый умный, давайте, пожалуй, на этом закончим. Спасибо.
raven19
21.04.2022 13:34-1Видимо вы даже прочесть нормально не удосужились, первая ссылка в источниках...
Точно, Вы правы, до ссылок я уже не дошел, хотя видел их, поторопился с утверждением, но я искал ссылки сразу в районе цитат. Мне что нужно "перерыть" все источники. чтоб разобраться, что откуда? Видимо устал формировать "репорты об ошибках" к тому времени...
Все поняли, что вы самый умный,
Господи, как примитивно... Ещё мне не хватало, чтоб с Вами чем-то меряться.
gerasiov
21.04.2022 13:24+4>как это не странно
как это ни странно. извинитеtarekd
21.04.2022 13:40+1В чужом глазу соринку видим, а в своём и бревна не замечаем. Спасибо что заметили!
raven19
21.04.2022 13:41согласен, спасибо. Кстати, на комментариях отчеты об ошибках не работают!! А очень жаль. А то, что ошибки бывают практически всегда, надеюсь, что с этим тезисом спорить никто не будет. Вопрос в том, сколько их...
gerasiov
21.04.2022 14:02Ну я скорее к тому, что в целом ошибки совершают все, некоторые физически не способны вычитать даже простой текст - это такая особенность работы мозга. Да читать это бывает тяжело, глаз цепляется, но вы, блин, тут развели в комментах что-то странное. Заметил ошибку - отправил в личку. Заодно предложил помощь в вычитке в будущем. Ну, ей богу, настрочили текста больше чем в оригинальной заметке.
homm
21.04.2022 14:54Ну, блин, до писателя Вам, как до Китая… Ну и кто мешает воспользоваться услугами "по вычитке и корректировке тестов "? Религия не позволяет?
А что вам не позволяет писать свои претензии (которым имхо тут не место в таком количестве) хотя бы уважительно?
RomanSt
21.04.2022 16:31+1Я за грамотное написание. Позволю себе отметить несколько фактов.
1. Вы пишите об ошибках автора, которые он уже признал.
2. Вы сами совершаете ошибки. Например, во втором абзаце вы пишите "что либо" без дефиса.
3. Пост очень большой, но не по теме и публичный.
Лично я (читатель) делаю вывод, что этот пост написан, чтобы самоутвердиться. Пишите в личку!
Автор, извините, что не по теме поста.
piratarusso
21.04.2022 15:00Python существенно отличается от других языков программирования меньшими проблемами при смене версий. Если у разработчиков python получится сохранять обратную совместимость и дальше, то любые улучшения производительности будут большим плюсом.
Revertis
21.04.2022 15:15-1Python существенно отличается от других языков программирования меньшими проблемами при смене версий.
В Расте их вообще почти нет.
domix32
21.04.2022 16:20Ну, как сказать. MSRV policy и разбивка на edition неспроста появились. Плюс, начиная с 1.0 изменения имеют определенные гарантии обратной совместимости. Так что с питоном думаю они примерно одинаковы в этом плане.
HemulGM
21.04.2022 15:38Нельзя ни как сохранить полную обратную совместимость, если вносится что-то действительно значимое. Если остается полная совместимость, значит либо:
1. Остается куча легаси или деприкейтед (подобное мы можем наблюдать в Windows)
2. Нет значительных изменений
3. Код настолько идеальный, что его дальше некуда улучшать (смешно)Anisov Автор
21.04.2022 16:02На данный момент заявляется полная обратная совместимость, конечно поживём-увидим, но я считаю, что им это удастся сделать, ибо под обратной совместимостью понимается две вещи: 1) запуск старого python кода, который работал на версиях 3.10, 3.9 и т.д. 2) совместимость с C API, которое используется, например, в numpy. Первая задача достаточно просто решается, и с ней проблем, я думаю, не будет, за исключением определённых вещей, которые будут удалены, т.к. устареют в этой версии, но если вы не используете депрекейтед код, то проблем не будет. А вот второе, это, конечно, задача по сложнее с точки зрения сохранения обратной совместимости, возможно, будет переходный этап, возможно, вообще не затронут конечные интерфейсы, объекты и в целом API, но одно ясно точно, это не будет такой же переход как с 2 на 3, а будет постепенное развитие, а не революция, Гвидо сильно против любой поломки совместимости. Главная цель - это ускорить так, чтобы ничего переписывать конечным пользователем не нужно было. Поэтому сейчас основная работа сосредоточена в ядре, то до чего руки обычных пользователей не дотягиваются или работа идет исключительно через обёртки.
piratarusso
22.04.2022 10:04Как ни странно, но в рамкакх ветки 2 и ветки 3 в основном это до сих пор удавалось. Так что к обратной совместимости пользователи привыкли. Разработчики фиксят обычно те немногочисленные ошибки, которые крайне редко, но таки появляются.
CrashLogger
21.04.2022 15:08+6Прочитав заголовок, подумал, что ускорили работу Python в Windows 3.11. Ан нет, придется и дальше страдать.
AcckiyGerman
Я помню на хабре несколько лет назад был пост, где разработчик переработал систему запуска питона, значительно ёё ускорив, и создал соответствующий пул-реквест.
Но объем кода был достаточно большой, и не нашлось желающих его проверить. По итогу разработчик обратился напрямую к Гвидо, который отшил его, сказав, что если не нашлось ведущих контрибьютеров питона, которые хотят проверить код данного ускорения, то наверное это ускорение никому не надо.
Теперь мы видим, что ситуация меняется, что не может не радовать.
qark
Вот этот пост: habr.com/ru/post/314062