https://nickb.dev/blog/the-dark-side-of-inlining-and-monomorphization/ #perf

Зумеры, в очередной раз, переизобретают и переописывают то, что всем заинтересованным людям давно известно - чрезмерный inline-инг (современное его название - мономорфизация, но кому какое дело?) - не только полезно, но и очень вредно.

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

#terminal #rant

https://www.jeffquast.com/post/ucs-detect-test-results/
https://ucs-detect.readthedocs.io/results.html

Монументальный текст (от автора python wcwidth) про то, как разные терминалы работают со всякими "странными" unicode последовательностями.

"Странными" в данном контексте я называю такие последовательности, которые занимают на экране терминала не столько же клеток, сколько в них юникодных символов. Последовательности нулевой ширины, эмодзи, какие-то широкие азиатские иероглифы, и так далее.

Unicode, в попытке объять необъятное (== унифицировано описать все разнообразие способов передать символьную информацию), идет куда-то не туда.

Вот раньше все было просто - 1 char == 1 клетка на экране (может быть, разной ширины, если не monospace). Потом стало сложнее, разных символов стало настолько много, что они перестали влезать в 1 байт, потом в 2. Были изобретены разные транспортные кодировки, типа utf8, но внутри лежал все тот же самый 4-байтный codepoint.

То, что происходит сейчас, напоминает попытку запихнуть произвольную интерпретируемую программу поверх этих codepoint, чтобы получить эффекты, которых раньше получить было нельзя.

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

Потому что как еще унифицировать анимированное эмодзи с какахой и, не знаю, символы нулевой ширины со всем остальным зоопарком, я не понимаю.

Как нужно?

1) Нужно пытаться перестать запихнуть в Unicode всякого рода symbol of the day, типа анимированной какахи.

2) Нужно сказать, что терминал - он не для вывода произвольного Unicode текста, а только для такого текста, который имеет разумное (две клетки на символ - неразумное, усложняет вообще все в разы) погружение в концепцию клеток фиксированной ширины. Для всего остального есть браузер.

(я, например, даже не расстроюсь, если в терминале останется только первые 128 символов из ASCII, но, врочем, я и полезность юникодных имен файлов до сих пор не очень осознал)

https://github.com/systemd/systemd/pull/30547 #suid

"add new "uid0" command as alternative multi-call interface for systemd-run, as sudo replacement #30547"

Ну, все, идея пошла в main stream.

Даже, знаете ли, немного обидно, потому что -1 selling point, и уже нельзя сказать про почти любой пакетный менеджер что-то в стиле "а, это там, где еще не вычистили suid бинари с fs", и презрительно покривить носом.

Терпеть не могу статьи в стиле псевдомонолога персонажей в чьей-то там голове, но, тем не менее, свежий подход к тому, как можно сопрягать go с другими компилируемыми языками, минуя cgo:

https://xeiaso.net/blog/carcinization-golang/

TL;DR - конпелируете библиотеку на Rust в #WebAssembly, и загружаете ее в Go через #wazero (pure go #WebAssembly #WASM #WASI runtime)

Что нам это дает? Нам это дает:

* безопасную песочницу
* без ограничений cgo (типа выполнения в отдельно выделенных потоках, и всякое такое)

(это отличается от ранее представленных способов, типа конпеляции всего в WebAssembly, и объединения через WebAssembly VM)

Понятное дело, что тут у нас в полный рост startup/warmup cost, и все, что с этим связано, но способ довольно интересный.

Subscriber's submission

Решил посмотреть, сколько займет времени переписать мои экзерсизы с #qtile (https://xn--r1a.website/itpgchannel/1437, потому что проект, кажется, мертв, мой патч там не то что не мержат, а даже и не смотрят - https://github.com/qtile/qtile/pull/4568), скажем, на #hyprland

Вот, полюбуйтесь, N-Stack layout буквально за копейки 2000 строчек довольно сложного кода - https://github.com/zakk4223/hyprNStack/blob/main/nstackLayout.cpp

Пока это только для очень, очень, упорных людей, а у меня столько времени нет. Мне бы хотя бы на десятичный порядок "дешевле" нужно.

Подожду, пока проект хоть немного подрастет, ну или поищу какое-нибудь другое место, куда можно встроиться.

#llvmweekly

https://github.com/llvm/llvm-project/commit/9783f28cbb15

Чуваки взяли, и применили clang-format на всю libc++. Респект, уважуха, поменьше бы проекты дрожали над историей, и не ссали переформатировать код для удобства чтения.

#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, то это будет счастье.

Две ссылки, которые особенно хороши вместе.

https://www.opennet.ru/opennews/art.shtml?num=60360
https://www.theregister.com/2023/12/27/bruce_perens_post_open/

Некто Брюс Перенс, известный oss склочник (https://xn--r1a.website/itpgchannel/145, известен он тем, что пытается нажиться на несуществующем коде, а, конкретно, на busybox, несмотря на то, что его кода там - закрывающие фигурные скобочки), решил, что существующие OSS лицензии не позволяют ему достаточно хорошо наживаться на несуществующем коде, и придумал какого-то очередного кадавра, который должен позволить перераспределить деньги от коммерческих компаний в его кошелек гармонизировать сосуществование коммерческих компаний с ним.

О как.

Для этого предлагается запилить какую-то новую лицензию, код по которой можно использовать, если ты прошел аудит в какой-то третьей компании/фонде, которые авторизованы делать такой аудит. Например, если они принадлежат Перенсу. И раз в год, все желающие использовать софт под этой лицензией, должны проходить такой аудит. А для этого они должны или участвовать в разработке OSS софта, или платить "куда надо" денег.

Там, где есть перераспределение чужого, там всегда есть и злоупотребление, как мы это все прекрасно понимаем. Поэтому понятно, что это влажные мечты, и они не имеют никакого отношения к реальности. Потому что настоящие игроки, стейкхолдеры, которые пишут 95% oss софта, под это никогда не подпишутся, так как они этот софт пишут не для "прямого" зарабатывания на этом софте денег (вот как Гугл пишет свой Хром, например)

И вторая ссылка - https://www.opennet.ru/opennews/art.shtml?num=60358

Разработчики Debian не хотят нести ответственность в рамках https://en.wikipedia.org/wiki/Cyber_Resilience_Act

В целом, это очень понятно - если ты ничего не получаешь за свой софт, то и материальную ответственность нести не можешь.

Это, конечно, поставило бы и Red Hat, и вот такую структуру Перенса, и разработчиков, которые решает подзаработать на open source, в интересное положение - хочешь денег, неси материальную ответственность.

Мне кажется, такой подход сделал бы переупаковку oss софта существенно менее прибыльным бизнесом.

#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://www.phoronix.com/review/ubuntu-x86-64-v3-benchmark

Миша с фороникса, в очередной раз, врет лжет накручивает статистику, в очередном странном бенчмарке.

На этот раз он сравнивает две сборки убунты - обычную x86_64, и оптимизированную под современные x86_64 ядра.

Что я имею сказать по поводу его исследования?

* https://www.phoronix.com/review/ubuntu-x86-64-v3-benchmark/4 - у него нет ожидаемого геометрического среднего всех тестов (а это самый лучший способ усреднять бенчмарки разной природы). Почему? Потому что, наверное, там пшик с постным маслом, вот почему.

* https://www.phoronix.com/review/ubuntu-x86-64-v3-benchmark/4 - вот возьмем тест, который дал самый большой отрыв - stress-ng по скорости копирования памяти. Я вас умоляю, там везде (что в ядре, что в glibc) runtime cpu dispatch, и этот тест должен показать одинаковые значения на одном и том же железе.

Я полез, почитал код stress ng - там 4 разных способа сравнить скорость memcpy - https://github.com/ColinIanKing/stress-ng/blob/master/stress-memcpy.c#L31

Понятное дело, что "настоящий" memcpy не дал бы такую просадку, наверняка он позвал что-то из builtin, naive, и все такое, что не имеет никакого отношения к реальности.

Писал, и буду писать, что Мише с фороникса веры нет, он или подпездывает в меру своих пристрастий, или в меру того, как ему кто-то подкинет деньжат (я свечку не держал, но вот мой предыдущий текст про clear linux явно на это намекает).

С наступающим

Хэнк Муди II SWEET MEMES

https://www.gentoo.org/news/2023/12/29/Gentoo-binary.html

Gentoo goes Binary!

Мне это, конечно, кажется странным.

Прелесть gentoo, на мой вкус, исключительно в ее use флагах. Без них - ну arch и arch, найдите 5 отличий, как говорится.

Если распространять бинарные сборки только для самых популярных наборов флагов - то cache hit у такой инсталляции должен быть очень мал.

А если пытаться распространять сборочный кеш для широкого набора флагов - то тут, конечно, всплывают лицензионные ограничения в полный рост, потому что не любой бинарь, который ты можешь собрать, используя кастомные use флаги, можно распространять.

По слухам, админ канала только проснулся, и начал доедать оливьешечку, и до новостей из мира IT ему пока дела нет, чего он и вам желает!

Вот я балда - КДПВ нарисовал, а текст добавить забыл.

https://www.pypy.org/posts/2023/12/pypy-moved-to-git-github.html
https://www.pypy.org/posts/2023/12/pypy-moved-to-git-github.html#motivation

PyPy переезжает в github.

"Open Source has become synonymous with GitHub, and we are too small to change that"

Продолжим славную традицию репоста новогоднего дайджеста от opennet, они лучшие!

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