https://www.bitecode.dev/p/python-312-what-didnt-make-the-headlines#%C2%A7the-performance-let-down

Тут вот коллега пишет, что python 3.12 не быстрее 3.11 на 5%, а довольно значимо медленнее (для теста использовался https://github.com/python/pyperformance).

"You'll notice that 14 tests run faster, but 79 run slower"

Да и даже по wall time всего теста там видно замедление.

Эх, где те (недавние) времена, когда нам обещали 50%-ое ускорение на каждый мажорный релиз?

#fast_python

#fast_python

https://www.opennet.ru/opennews/art.shtml?num=60352

А вот, пожалуйста, новый-кленовый JIT для python.

Вот цифры про perf:

"По сравнению с традиционным JIT-инструментарием (LLVM -O0) предложенный JIT обеспечивает в 100 раз более быструю генерацию кода и на 15% более быстрый результирующий код. По сравнению с компиляцией в WebAssembly (Liftoff) новый JIT генерирует код в 5 раз быстрее, а результирующий код работает на 50% быстрее. Если сравнивать новый JIT с оптимизирующим JIT (LuaJIT), использующим вручную написанный код на ассемблере, то предложенный вариант оказался быстрее в 13 из 44 тестах, а в среднем отстал по производительности на 35%, при существенном упрощении сопровождения и уменьшении уровня сложности реализации"

Конечно, с использованием LLVM, но, что интересно, LLVM нужен только в момент сборки самого JIT, но не в runtime.

Если что-то такое попадет в mainline, то это будет счастье.

#perf #fast_python

Мне стало интересно, что там за такой новый-кленовый JIT.

И почему он должен собираться именно LLVM? Это звучало вообще странно - как так, в runtime кодогенератор от LLVM не нужен, а во время сборки - нужен? Это что за магия такая?

Все оказалось довольно просто, достаточно было прочесть https://github.com/brandtbucher/cpython/blob/justin/Tools/jit/build.py, ну и немножко https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110899 (по этой ссылке содержится просьба к GCC добавить недостающие кусочки к gcc, чтобы можно было использовать не LLVM, а gcc)

(Немного в сторону от основной темы, авторы gcc, конечно, встали на дыбы, потому что как это так, не за ними все повторяют, а им надо что-то повторить за clang?

"Shouldn't we first discuss whether any of this, or particular aspects of it, are a good idea at all, before specifying behaviour that a random compiler happened to implement?")

В общем, суть в следующем: а давайте мы сконпелируем исходный текст интерпретатора с набором волшебных ключей, чтобы получившийся объектный код можно было растащить на кусочки, а потом из них собрать объектный код для байткода python?

Вот, допустим, у нас есть такой кусок байткода (это не питонячий байткод, но так будет понятнее):

...
mov A, B
...

Дальше в интерпретаторе есть огромный switch/case, где написано:

... 
if (opcode == 'mov') {
    auto op1 = getNextOp();
    auto op2 = getNextOp();
    auto& g = interpContext->globals;
    g[op1] = g[op2];
}
...

Далее мы компилируем этот файл в объектный код, и аккуратно вырезаем из него код, соответствующий только этому одному блоку

if () { ... }

После чего мы проходимся по всему байткоду, который был построен cpython, и заменяем в нем отдельные инструкции на вот эти вот кусочки заранее скомпилированного нативного кода.

Затем проходимся сверху скопипасченного объектного кода парой регулярок, и получаем код, который реально может быть выполнен!

От LLVM тут нужно, чтобы он сумел скомпилировать цикл интерпретатора для другого calling convention, а, конкретно, для такого специального CC, когда все регистры сохраняет callee. Видимо, так сильно проще получить код, который можно нарезать на независимые кусочки, которые далее можно "просто" конкатенировать. Я на получившиеся кусочки глазами не смотрел, поверил автору на слово.

UPD: вот paper, где описана эта техника copy and patch - https://arxiv.org/pdf/2011.13127.pdf , from https://aha.stanford.edu/sites/g/files/sbiybj20066/files/media/file/aha_050621_xu_copy-and-patch.pdf

UPD: утащю из комментов - https://xn--r1a.website/c/1469934025/21379

https://medium.com/top-python-libraries/microsoft-shuts-down-python-founders-core-team-cpython-team-disbanded-0ae603862d68

"However, yesterday, CPython core developer Brett Cannon revealed on LinkedIn that three core developers from the Faster CPython team — Eric Snow, Irit Katriel, and Mark Shannon — were included in Microsoft’s recent global layoffs"

#fast_python - от начала, и до конца.

https://pythoninsider.blogspot.com/2025/10/python-3140-final-is-here.html

А прямо очень хорошо:

* PEP 779: Free-threaded Python is officially supported
* https://docs.python.org/3/whatsnew/3.14.html#whatsnew314-tail-call-interpreter A new type of interpreter. For certain newer compilers, this interpreter provides significantly better performance. Opt-in for now, requires building from source.
* Official macOS and Windows release binaries include an experimental JIT compiler.

#fast_python

https://blog.miguelgrinberg.com/post/python-3-14-is-here-how-fast-is-it

TL;DR - новый питон прямо реально хорош, значимо быстрее (и в однопотоке, и в многопотоке), чем все предыдущие версии!

https://docs.python.org/3.14/whatsnew/3.14.html#whatsnew314-refcount - возможная причина такого значимого ускорения.

#fast_python

Вот у меня есть простой тест, рендерит несколько сотен jinja шаблонов, он не ускорился от слова совсем:

pg:home# time ./ix mut system
real  0m3.546s
user  0m3.168s
sys  0m0.172s

pg:home# ./ix build bin/python/14
READY /ix/store/F30M09jVrxzaVUcZUwtoI7-rlm-ephemeral/touch
pg:home# time /ix/store/F30M09jVrxzaVUcZUwtoI7-rlm-ephemeral/bin/python3 ./ix mut system
real  0m3.509s
user  0m3.148s
sys  0m0.154s

Не знаю, чего они там у себя намеряли.

#fast_python

В комментарии пришел коллега, насколько я понял, из python core team, и объяснил, что финансирование проекта про jit закончилось в начале лета, отсюда и статус deferred - https://peps.python.org/pep-0774/.

Такие печальные дела :(

#fast_python

Собрал, просто пропатчив сборочный тулинг - https://github.com/pg83/ix/commit/19aed62fa1034c825fa1481aa9b3d16b5785f432#diff-6dc895a4607269ae215c441f6eee0fc669a8d2c2971bf50ec2953f92b69399ecR30

Профита от jit не нашел, примерно нигде.

#fast_python

https://fidget-spinner.github.io/posts/faster-jit-plan.html

Грустный текст, про ускорение python, #fast_python

Грустный, потому что за пару релизов хотят получить 5 - 10 процентов #perf, при этом, это больше похоже на декларацию о намерениях, чем на конкретный план.

А получат, как и в прошлые разы, 2 - 3 процента на бенчмарках, которые не видны в проде.