#wasm #perf

Разобрался с отставанием wasmedge.

Чтобы все работало быстро, нужно пройтись по wasm с помощью его AOT компилятора, и тогда получается вот такой результат:

real  0m 0.62s
user  0m 0.57s
sys  0m 0.03s

Это уже довольно близко к нативной скорости выполнения того же бинаря.

Впрочем, скорость его AOT не впечатляет:

pg# time .../bin/wasmedgec \
    --optimize 3 \
    --enable-threads \
    .../brotli brotli
[2023-06-29 01:55:52.636] [info] compile start
[2023-06-29 01:55:52.669] [info] verify start
[2023-06-29 01:55:52.710] [info] optimize start
[2023-06-29 01:55:56.632] [info] codegen start
[2023-06-29 01:56:01.680] [info] output start
[2023-06-29 01:56:01.682] [info] compile done
[2023-06-29 01:56:01.686] [info] output start

real  0m9.117s
user  0m9.063s
sys  0m0.041s

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

Oracle запилили автоматический оптимизатор настроек ядра Linux, о как.

На моей памяти это уже вторая (а то и третья) такая попытка.

(быстрым грепом не нашел эту историю в интернете, если у вас есть под рукой - киньте ссылкой)

Но, насколько я помню, тогда оно не полетело, потому что:

* Linux был еще глючнее, чем сейчас.
* Многие комбинации параметров приводили к тому, что система просто вставала колом, с невозможностью тюнить ее дальше. С учетом первого пункта это было бомбически.
* Шум.

Интересно, как Oracle решили эти проблемы.

https://rockylinux.org/news/keeping-open-source-open/

Не менее мерзотный текст от Rocky Linux, с описанием того, что они собираются сделать в ответ на действия RH.

В целом, все просто - они заявляют, что с болтом клали на EULA от RH, и будут выковыривать сурсы отовсюду, куда дотянутся. В основном, через облачные инсталляции RH.

Почему этот текст не менее мерзотный?

Вот из-за этого абзаца:

"These methods are possible because of the power of #GPL. No one can prevent redistribution of GPL software. To reiterate, both of these methods enable us to legitimately obtain RHEL binaries and SRPMs without compromising our commitment to open source software or agreeing to TOS or EULA limitations that impede our rights. Our legal advisors have reassured us that we have the right to obtain the source to any binaries we receive, ensuring that we can continue advancing Rocky Linux in line with our original intentions"

Как обычно, это "полуправда", призванная скрыть суть происходящего.

Да, для GPL софта они имеют право получить исходники и SRPMS таким образом.

А вот для не-GPL бинарников - не имеют.

И, на самом деле, довольно много системного софта в Linux не идет под GPL (практически весь графический стек, не считая конечных тулкитов - permissive, например).

В глубине души, я, конечно, больше на их стороне, но, КМК, им надо быть более аккуратными.

#wasm

От сборки примитивной ерунды до запускающегося интерпретатора python прошло не очень много времени:

pg# ./ix run bin/wasm/edge bin/python/11/wasi --target=wasi32 -- wasmedge --enable-all '$(command -v python3.wasm)' --help
usage: python3.wasm [option] ... [-c cmd | -m mod | file | -] [arg] ...
Options (and corresponding environment variables):
-b     : issue warnings about str(bytes_instance), str(bytearray_instance)
         and comparing bytes/bytearray with str. (-bb: issue errors)
-B     : don't write .pyc files on import; also PYTHONDONTWRITEBYTECODE=x
-c cmd : program passed in as string (terminates option list)
-d     : turn on parser debugging output (for experts only, only works on
         debug builds); also PYTHONDEBUG=x
-E     : ignore PYTHON* environment variables (such as PYTHONPATH)
-h     : print this help message and exit (also -? or --help)
-i     : inspect interactively after running script; forces a prompt even
         if stdin does not appear to be a terminal; also PYTHONINSPECT=x
-I     : isolate Python from the user's environment (implies -E and -s)
-m mod : run library module as a script (terminates option list)
-O     : remove assert and __debug__-dependent statements; add .opt-1 before
         .pyc extension; also PYTHONOPTIMIZE=x
-OO    : do -O changes and also discard docstrings; add .opt-2 before
         .pyc extension
-P     : don't prepend a potentially unsafe path to sys.path
-q     : don't print version and copyright messages on interactive startup
-s     : don't add user site directory to sys.path; also PYTHONNOUSERSITE
-S     : don't imply 'import site' on initialization
-u     : force the stdout and stderr streams to be unbuffered;
         this option has no effect on stdin; also PYTHONUNBUFFERED=x
-v     : verbose (trace import statements); also PYTHONVERBOSE=x
         can be supplied multiple times to increase verbosity
-V     : print the Python version number and exit (also --version)
         when given twice, print more information about the build
-W arg : warning control; arg is action:message:category:module:lineno
         also PYTHONWARNINGS=arg
-x     : skip first line of source, allowing use of non-Unix forms of #!cmd
-X opt : set implementation-specific option
--check-hash-based-pycs always|default|never:
         control how Python invalidates hash-based .pyc files
--help-env      : print help about Python environment variables and exit
--help-xoptions : print help about implementation-specific -X options and exit
--help-all      : print complete help information and exit
Arguments:
file   : program read from script file
-      : program read from stdin (default; interactive mode if a tty)
arg ...: arguments passed to program in sys.argv[1:]
pg# 

Впрочем, сам интерпретатор пока не очень работает:

pg# ./ix run bin/wasm/edge bin/python/11/wasi --target=wasi32 -- wasmedge --enable-all '$(command -v python3.wasm)' 
Exception ignored error evaluating path:
Traceback (most recent call last):
  File "<frozen getpath>", line 353, in <module>
OSError: [Errno 0] Error
Fatal Python error: error evaluating path
Python runtime state: core initialized

Current thread 0x00000000 (most recent call first):
  <no Python frame>

На phoronix обсуждают какую-то презу, в которой объясняется, почему Linux не используют в mission critical системах.

https://www.phoronix.com/news/Linux-On-Airplanes-Challenges

КМК, приведенный выше слайд очень хорошо описывает культуру разработки ядра (а, точнее, ее полное отсутствие).

#linux #kernel

#GNOME #gtk #ssd

https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6161

Продолжение темы про server side decorations, жирно, годно.

На этот раз господа из gtk прямым текстом говорят, что wayland - им не указ:

"There is no debate. And this is not a standard. It is an experimental protocol that somebody slapped the xdg name on and merged into the wayland repos. It is not implemented by anybody except sway and kwin"

И ответ:

"Please refrain from making fun of the Wayland community this way. We've worked very hard to reach a consensus among all wayland-protocols members, and it feels like you're dismissing this work"

Тут вот активно форсят тему про планирующийся бой Маска и Цукерберга, а я вот, конечно, хотел бы посмотреть, как подерутся Simon Ser и Clasen, например.

#llvm

https://reviews.llvm.org/rG75a1797044fc

Поддержка fat lto .o файлов.

Сделано это изящным (нет) хаком:

"The new pipeline initially clones the module and runs the
selected (Thin)LTOPrelink pipeline, after which it will serialize the
module into a .llvm.lto section of an ELF file"

Натурально, положили IR в отдельную секцию в .o файле.

Получается, что, если, в итоге, будет использован LTO, то дополнительная работа по оптимизации и подготовке объектного кода будет выброшена на ветер.

Думаю, сделано это от бедности, чтобы можно было протащить IR через системы сборки и пакетирования, которые ничего про это не знают, до LTO линкера.

Если уметь пересобрать все дерево зависимостей одним махом с нужными флагами, то все эти приседания, очевидно, не нужны.

https://www.neversaw.us/2023/06/30/understanding-wasm/part2/whence-wasm/

#wasm

Классный экскурс в историю WebAssembly.

Очень понятно объясняется, почему WebAssembly именно такой, и как так получилось.

КМК, ключевой абзац этого текста:

"WebAssembly pulled the same magic trick C did: it extracted an existing, useful abstract machine definition from several concrete implementations, like finding David in the block of marble. Rather than requiring that browser vendors implement a second virtual machine, WebAssembly support could be added incrementally, sharing code between the JS and WASM runtimes. WebAssembly machine definition supports C's abstract machine — C, C++, Golang, and Rust can compile to this target — acting as a virtual instruction set architecture"

WebAssembly - это такие "кишки наружу" от уже существующих оптимизирующих JavaScript JIT, типа V8/TraceMonkey, позволяющих эффективно таргетировать WEB как платформу для быстрого выполнения кода на разных компилируемых языках, типа C++/Rust/etc, без прослойки вида JavaScript/Emscripten/asm.js.

#wasm #bootstrap

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

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

Но, с появлением таких штук, как #wasi, и как биндинги в WebGL, на WASM можно довольно удобно смотреть как на API boundary.

Что это значит?

Для кода, исполняющегося в песочнице WASM, вызывающая сторона может четко описать, какие внешние вызовы ей доступны:

* https://wasi.dev/ - набор API для кросс-пдатформенных вызовов в OS.

* https://wasix.org/ - POSIX API

* Браузеры, например, предоставляют WASM коду возможность дергать WebGL функции, то есть, к аппаратному ускорению графики.

* Аппаратное декодирование видео

* ...

Возникает очень простая мысль: а зачем линковаться с реализацией opengl (статически или динамически), если тебе ее может предоставить WASM runtime?

Картина маслом - все GUI приложения в системе компилируются в WASM, можно сразу в AOT представление, а различия в аппаратной начинке систем скрыты в WASM runtime, который, единственный в системе, линкуется с настоящей реализацией opengl.

Что туда было бы хорошо засунуть, кроме opengl?

* vulkan
* multimedia api, типа кодеков, микширования звука
* dbus
* алгоритмические ошметки сетевых стеков (кодеки bluetooth и прочее)

Короче, все, что:

* имеет стабильный и слабо меняющийся ABI (поэтому библиотеки виджетов и прочие freetype/harfbuzz под это не попадает)
* используется много кем

Дальше Остапа понесло:

* FUSE, VFS(?), mount namespaces
* какие-то другие запчасти от контейнеризации

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

#rant

#RH - контора пидорасов!
#GNOME - контора пидорасов!

У меня сломался waybar, с довольно странной ошибкой:

[2023-07-05 18:52:33.631] [warning] module sway/workspaces: Disabling module "sway/workspaces", Unable to connect to the SYSTEM Bus!...

Быстрое расследование с помощью strace показало, что программа хочет коннектиться к /run/dbus/system_bus_socket, вместо привычного /var/run/dbus/system_bus_socket

Коллеги из glib, почему-то, решили, что spec им не указ, и самовольно заменили путь по умолчанию - https://github.com/GNOME/glib/blob/main/gio/gdbusaddress.c#L1338-L1346

"While the D-Bus specification says this must be /var/run/dbus/system_bus_socket"

При этом:

* Они пишут, что для систем, где /run == /var/run, это, мол, не проблема. Гже-то написано, что это всегда так?

* Они считают, что дали возможность заменить этот путь на старый, через настройку конфигурации glib - https://github.com/GNOME/glib/blob/main/NEWS#L335

Но, конечно, они всех обманули - https://github.com/GNOME/glib/blob/main/meson.build#L130-L139

Почему? Потому что они не берут эту настройку as is, а делают вот так - glib_runstatedir = glib_prefix / get_option('runtime_dir')

То есть, по сути, они довольно жестко навязали использование /run для хранения сокета dbus.

Я не знаю, что это - долбоебизм разработчиков, или намеренное желание заставить всех хранить сокеты сервисов в /run, а не в /var/run.

Совершенно не хочу дискутировать то, как правильно, бесит сам факт навязывания "в тихую".

https://github.com/0xpayne/gpt-migrate

"Easily migrate your codebase from one framework or language to another"

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

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

Мир меняется, быстро и (пока) не очень заметно, прямо сейчас, и за этим очень интересно наблюдать.

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

#rant #bootstrap

Решил я себе собрать https://github.com/openSUSE/hwinfo - это такая тулза для сбора информации про систему, развивается, судя по всему, под крылом SUSE.

Программа собирается исключительно чудом, а, точнее, двухкратным запуском make:

make[1]: *** No rule to make target 
    '.../src/libhd.a', 
    needed by 'hwinfo'.  
    Stop.
make[1]: *** Waiting for unfinished jobs....
ar: warning: creating ../src/libhd.a
make[3]: *** No rule to make target 
    'cdb/isdn_cdb.h', 
    needed by 'cdbisdn.o'.  
    Stop.
make[3]: *** Waiting for unfinished jobs....
description(enter:now): under development

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

И это, судя по беглому анализу Makefile, by design.

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

А дальше сборка зависла минут на 10, и не подавала признаков жизни. Разве что, крутила в какой-то самосборной программе 100% CPU.

Я подумал, что это все мой musl, и полез копать патчи из alpine, но, пока читал, оно как-то завершилось, выдав на экран следующее:

data written to "hd.ids"
log written to "hd.log"
statistics:
  1113 inconsistencies fixed
  20 errors, 20 resolved
  60483 items in
  45468 items out
data written to "hd_tiny.ids"
log written to "hd_tiny.log"
statistics:
  0 inconsistencies
  0 errors
  45468 items in
  377 items out
llvm-ar: warning: cre

Я воробей стреляный, говнокода на С повидал немало, и знаю, что коллеги очень редко в С изобретают хеш-таблицу, а вот квадрат операций для удаления 15000 элементов из списка длиной в 60000 они соорудить могут - https://github.com/openSUSE/hwinfo/blob/master/src/ids/check_hd.c#L2124-L2127 (собственно, проблема, что мы матчим каждый элемент с каждым, прежде чем удалить).

Про аццкий Makefile, который не знает, что такое PREFIX, и чем он отличается от DESTDIR, я вообще молчу - https://github.com/openSUSE/hwinfo/blob/master/Makefile#L105

У разрабов из SUSE нет чувства прекрасного, не используйте ее, если можете, потому что если люди вот так наплевательски относятся к мелочам, то все остальное тоже будет из жопы.

Наткнулся на совершенно прекрасный текст, в котором автор libjpeg-turbo (самый популярный декодер jpeg, на его основе сделан mozjpeg - самый популярный энкодер) рассказывает, почему он не стал поддерживать новые фичи из libjpeg 9 (девятая версия референсной имплементации).

https://libjpeg-turbo.org/About/Jpeg-9

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

Вот, реально, чувак с сильным мнением решил, что сам знает как лучше, и ему никто не нужен, чтобы покатить фичу в прод (DARIA-5005, для тех, кто помнит).

Конечно, авторы альтернативных реализаций не хотят поддерживать эту дичь.

Короче, почитайте, походите по ссылочкам, там вкусно.

#wasm #harfbuzz

Не прошло и месяца после коммита с поддержкой wasm шейперов, как код проехал в прод - https://github.com/harfbuzz/harfbuzz/releases

(кстати, в прошлом тексте я ошибся, предположив, что код будет заниматься рендерингом - код будет заниматься исключительно шейпингом текста, то есть, расстановкой шрифтовых глиф по холсту - пример того, что было до, и после - https://github.com/simoncozens/wasm-examples)

Все это плохо пахнет, если вы понимаете, о чем я:

* мало времени от демонстрации намерений до релиза, как будто кто-то не (напомню, harfbuzz пилит сотрудник Гугла на зарплате) хотел серьезного обсуждения этой фичи.

* https://github.com/harfbuzz/harfbuzz/blob/main/docs/wasm-shaper.md - поверхность взаимодействия этого кода с harfbuzz весьма широка, и я не уверен, что ее можно норм реализовать, если ты - не harfbuzz. Похоже на попытку запилить очередной vendor lock in - если хотите использовать крутой шейпер из шрифта, берите harfbuzz. И чем это пижже ситуации с интерпретатором байткода из TrueType шрифтов? Отделаться тут общими словами "ну это только незначительные улучшения шейпера" - так не выйдет, потому что вот даже тут уже показано, как таки заэмбеддить настоящий растеризатор шрифтов в такой программируемый шрифт - https://github.com/simoncozens/wasm-examples

Ну и, конечно, все примеры таких программных шейперов запилены на Rust, хотя, конечно, тут сложно было ожидать чего-то другого:

* wasm target в Rust запилен много лучше, чем в других языках, хотя бы потому, что С++ в #wasm положить тяжело, так как в нем нет никакой поддержки для setjmp/longjmp/прочих способов нелокального code path (e.g. исключений)

* хайп, куда же без него

https://vole.wtf/scunthorpe-sans/

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

А какую красоту можно будет навернуть, если добавить туда программный шейпер на #wasm?

Еще я придумал мега формат для хранения и компрессии вообще всего - приложение прокидывает в wasm VM свою объектную модель, а любой сохраненный файл (документ, картинка, etc) - это просто программа на wasm, которая, дергая эту объектную модель, получает нужный результат.

Больше не нужны новые форматы для компрессии - просто пишешь рядом с данными wasm байткод по их распаковке. Ну, ладно, ладно, где-то еще нужно будет хранить всякие там веса, и прочие данные для декодера.

Будни #bootstrap

Я тут собирал protobuf-c (не спрашивайте, он нужен для unbound), и во второй раз в жизни использовал хак #define private public!

Не, реально - https://github.com/pg83/ix/blob/main/pkgs/bin/protoc/c/ix.sh#L30

Зачем?

Несколько разу же писал, что, если посадить несколько очень умных людей заниматься какой-нить лютой херней, типа #protobuf (прошлый #rant был про #grpc, ну и про Тома Хуйкина с его #ncurses можно вспомнить #ball_lick), то они начинают выдумывать себе (это пофиг), и нам (а вот это уже печально) задачи на пустом месте.

https://github.com/protocolbuffers/protobuf/blob/main/src/google/protobuf/descriptor.h#L1901-L1906

Вот, зачем-то скрыли метод, позволяющий узнать, в каком синтаксисе написан файл - втором, или третьем. И заботливо облизали это место с помощью пары макросов, призванных рассказать, что же я должен сделать с этим, по мнению авторов protobuf.

Дело-то хорошее! Надо же загодя подготовиться к внедрению четвертой версии синтаксиса (спойлер - нет, не надо https://groups.google.com/g/protobuf/c/Xpl4mw4zM_M), поэтому надо проверять фичефлаги, а не версию. А то вдруг вся работа закончится, а ипотека еще не выплачена!

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

На "сладкое" похвастаюсь, насколько же иногда мои "процедурные" патчи проще, чем вручную накладываемые и периодически переделываемые под новые изменения в upstream diff/patch.

Вот patch в arch linux, чтобы protoc-c собирался с более свежим protobuf - https://gitlab.archlinux.org/archlinux/packaging/packages/protobuf-c/-/blob/main/66a0b0d2.patch

А вот мой процедурный - https://github.com/pg83/ix/blob/main/pkgs/bin/protoc/c/ix.sh#L13-L20

Мне кажется, он более явно (и просто) выражает мое намерение.

https://www.oracle.com/news/announcement/blog/keep-linux-open-and-free-2023-07-10/

Oracle пытается троллировать RH/IBM, и выставить себя главным другом open source вообще, и Linux в частности.

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

"Главные борцуны за свободу Linux", my ass.