Серия статей про peg parser от Гвидо. https://medium.com/@gvanrossum_83706/peg-parsing-series-de5d41b2ed60

#fast_python

От "смотрите, какую клевую штуку я вчера прочитал в википедии", через "а вы знаете, я вдруг понял, что парсер в Питоне сосет"(а то это не было очевидно и до?), до "я переписал парсер Питона!".

Вообще, местами тошно смотреть, что делают былые крутаны со своими проектами. Тот же Гвидо со командой в течении ряда лет отвергал огромное число оптимизаций в интерпретатор Питона:

1) Потому что есть PyPy
2) Потому что jit сделает интерпретатор нечитаемым
3) Со скоростью и так все норм
4) Потому что нельзя менять API модулей

Чтобы не быть голословным, Гвидо on tail recursion:
https://neopythonic.blogspot.com/2009/04/tail-recursion-elimination.html

jit-компиляторы Питона можно найти в большом количестве, но до mainline CPython не дошло ничего.

И тут, ВНЕЗАПНО, после перехода в Microsoft, Гвидо решает заняться скоростью Питона, и обещает ускорить его в несколько раз. (https://github.com/faster-cpython/ideas, https://thenewstack.io/guido-van-rossums-ambitious-plans-for-improving-python-performance/) Конечно, сколько лет сам этому мешал, там непаханое поле, в несколько раз - это даже не начать приближаться к javascript(https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/python.html)

И ускорит, будьте уверены. И напишет еще 10 клевых постов. А вот то, что это могло сделать 2 - 3 хорошо мотивированных студента, просто возможности не было, никто и не вспомнит.

Интересных ссылок в последние дни нет.

Разве что:

* Новая Зеландия отменила контракт со штатным колдуном. https://boingboing.net/2021/10/13/official-city-wizard-fired-from-new-zealand-city-after-over-20-years-of-public-service.html Оригинальная ссылка недоступна, возможно, происки колдуна.

* Вышла совершенно ничем не примечательная OpenBSD 7.0 Ссылку на changelog не кидаю, там ничего нет. Зато, как обычно, с каждым новым релизом OpenBSD разработчики выкладывают какую-то графоманскую мелодию, которой можно насладиться тут - https://www.openbsd.org/lyrics.html#70 Треш, угар, содомия.

* Российская Государственная Открытая Лицензия - https://habr.com/ru/news/t/583156/ Сейчас запилят православный github, тогда заживем.

* Переписка про удаление GIL из Python - https://mail.python.org/archives/list/[email protected]/thread/ABR2L6BENNA6UPSPKV474HCS4LWT26GY/

Вот что пишет г-н Гвидо про nogil: #gil #fast_python

"To be clear, Sam’s basic approach is a bit slower for single-threaded code, and he admits that. But to sweeten the pot he has also applied a bunch of unrelated speedups that make it faster in general, so that overall it’s always a win. But presumably we could upstream the latter easily, separately from the GIL-freeing part."

"Я с удовольствием использую идеи автора в своем проекте по ускорению Python"

На мой взгляд, план этот потерпел фиаско. #fast_python

https://github.com/faster-cpython/ideas/blob/main/main-vs-310.rst

(Кстати, fellow kids, учитесь составлять презы - невнимательный читатель может подумать, что ускорили в 1.5 - 2 раза, а geometric mean - всего +25%)

Ускорили на четверть, хотя, по плану из https://github.com/markshannon/faster-cpython/blob/master/plan.md, каждый следующий релиз должен давать +50%, отложили релиз 3.11 еще на несколько месяцев, потому что он ведет себя нестабильно - https://www.spinics.net/lists/fedora-devel/msg302880.html

https://news.ycombinator.com/item?id=32002057

А что с удалением GIL? ХЗ, я не заметил какой-то активности про внедрение https://github.com/colesbury/nogil #nogil

Гвидо - на мыло, я так думаю.

https://github.com/faster-cpython/ideas/blob/main/3.13/README.md
https://github.com/faster-cpython/ideas/blob/main/3.12/README.md

#fast_python

Закончил читать два фундаментальных (если считать ссылки) текста про грядущие оптимизации python.

Если раньше я выражал здоровый скептицизм про эти планы, то теперь готов заявить сдержанный оптимизм - планы звучат достаточно "сложно", чтобы быть интересными, а не просто "ну мы как-то все ускорим в 100500 раз".

Oh, fun fact - Гвидо, похоже, отодвинули от процесса - https://github.com/faster-cpython/ideas/commits/main

Совпадение? Хм...

#fast_python #nogil

Чувак этот (colesbury), судя по всему, таки войдет в историю, потому что коллеги собираютс принять proposal про nogil python: https://discuss.python.org/t/a-steering-council-notice-about-pep-703-making-the-global-interpreter-lock-optional-in-cpython/30474 https://www.opennet.ru/opennews/art.shtml?num=59518

Коллеги, видимо, научились тому, как не надо делать масштабные внедрения, потому что:

"We do not want to create a permanent split between with-GIL and no-GIL builds"

"We do not want another Python 3 situation, so any changes in third-party code needed to accommodate no-GIL builds should just work in with-GIL builds"

"This is not Python 4"

В какие времена живем!

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://t.iss.one/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 - от начала, и до конца.