#perf #wasm

Ну вот я, с помощью лома и такой-то матери, собрал нетривиальное приложение, которое actually do something - компрессор brotli.

И потестил его в разных runtime, которые у меня уже были, vs. нативное выполнение:

pg# cat g | time .../brotli -1 -c > qw.brotli.1
real  0m 0.50s
user  0m 0.46s
sys  0m 0.03s
pg# cat g | time .../wasmedge \
    --enable-all \
    .../brotli -1 -c > qw.brotli.2
real  1m 2.35s
user  1m 2.27s
sys  0m 0.04s
pg# cat g | time .../iwasm \
    --llvm-jit \
    .../brotli -1 -c > qw.brotli.3
real  0m 2.71s
user  0m 5.86s
sys  0m 0.06s
pg# cat g | time .../iwasm \
    --fast-jit \
    .../brotli -1 -c > qw.brotli.4
real  0m 1.21s
user  0m 2.20s
sys  0m 0.06s

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

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

#wasm

Второго Курцвейла #future из меня все никак не получается, потому что, как обычно, я горазд предсказывать уже случившиеся события.

https://wasix.org/

https://github.com/wasix-org/wasix-libc

Вот, почти полный POSIX wasm runtime. К сожалению, пока работает только в https://wasmer.io/

#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

#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>

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 есть только в одном рантайме, но, я надеюсь, однажды это можно будет сделать "просто".

#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 байткод по их распаковке. Ну, ладно, ладно, где-то еще нужно будет хранить всякие там веса, и прочие данные для декодера.

https://github.com/serde-rs/serde/pull/2590 #blob

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

Меня больше, чем вся эта история с бинарным блобом, заинтересовала вот эта вот папочка - https://github.com/serde-rs/serde/tree/bfcd44704f847ac5a9f3072e102e803b5ebbef31/precompiled/proc-macro2 (ее уже нет в транке, потому что выпилили всю precompiled/ историю).

Я вот как в этом вот анекдоте:

- Василий Иваныч, сколько будет ноль целых пять десятых плюс одна вторая?
- Нутром чую, что литр, а доказать не могу!..

Нутром чую, что в этой папочке лежит реализация proc_macro, которая не требует загрузки .so в rustc, а работает через subprocess. Ну или я тогда не понимаю смысл этого precompiled binary - что там лежало-то?

Раскопки приводят к https://github.com/dtolnay/watt (от того же автора):

"Watt is a runtime for executing Rust procedural macros compiled as WebAssembly"

Короче, в конце тоннеля забрезжил свет, возможно, у меня получится прикрутить эту штуку к Rust, чтобы она использовалась вместо реализации по умолчанию, и не требовала загрузки свежесобранной .so в rustc. То, что там #wasm - это дело десятое, главное, что в виде отдельного бинаря.

https://flak.tedunangst.com/post/www-which-wasm-works

Вот, коллега тоже сталкивается с проблемами "а как же запустить простую программу, собранную в WebAssembly".

При этом коллега не собирал ничего сложного, а "всего лишь" собрал JpegXL кодек.

В общем, пользовательский опыт в #wasm, если не брать песочницы браузеров, пока довольно неубедительный.

https://github.com/ocornut/imgui/releases/tag/v1.90

Люблю рассматривать релизы #imgui, потому что там всегда есть список новых приложений, которые его используют.

Это вообще какая-то совершенно потрясающая вещь - в списке каждый раз 10 - 20 новых приложений, это примерно столько же, сколько во всем Gnome core.

Судя по всему, на imgui очень легко писать сложные gui, нужные для тулинга, и которые нужно написать быстро, а завтра - выкинуть. И в этом процессе нет места вылизыванию blur на уголках окон по 100500 раз.

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

Мне очень импонирует идея gui как очень тонкой прослойки над системным 3D API, потому что все классические gui типа qt/gtk, которые интегрировали 3d постфактум, сделали это плохо, неполно, и поэтому ты не знаешь, какая часть сцены у тебя отрендерится в 3d, и что приведет к тому, что случится 100500 копирований какого-нибудь буффера из/в память видеокарты.

К сожалению, в Linux 3d драйвера - это .so в userspace, вместо того, чтобы быть каким-нибудь dbus daemon, который бы умел кешировать и компилировать шейдерные программы, что не очень изящно ложится в мою модель статической линковки (бинари довольно заметно распухают, это не то чтобы сильно важно, но как-то "неаккуратно").

Поэтому я, конечно, очень жду, когда gui можно будет компилировать в что-то типа #WASM #WASI, и чтобы 3d драйвера жили исключительно в одном бинаре с WebAssembly VM, о как. Это, если что, не влажная фантазия, у вас прямо сейчас так работает webgl в браузере!

https://www.opennet.ru/opennews/art.shtml?num=60206
https://hacks.mozilla.org/2023/11/introducing-llamafile/

Портабельная запускалка моделек (это хайп), один бинарь может работать на нескольких OS/arch (а вот это вот интересная часть)!

Самое первое известное мне невасянское использования cosmopolitan libc от #justine https://justine.lol/cosmopolitan/

Мне идея cosmopolitan не очень нравится, потому что это хак, в плохом смысле этого слова. Индустрии нужно что-то такое, но я бы хотел видеть в этом месте #WASM, или что-то подобное.

Ну и как я когда-то подметил, Justine катится на волне хайпа от ML.

Терпеть не могу статьи в стиле псевдомонолога персонажей в чьей-то там голове, но, тем не менее, свежий подход к тому, как можно сопрягать 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, и все, что с этим связано, но способ довольно интересный.

#wasi #wasm #webassembly #bootstrap

https://determinate.systems/posts/nix-wasm/

Вот, коллега очень верно пишет про "nix as a meta build system", для сборки кода в WASI. Но, как это часто бывает, начал он за здравие, а кончил тем, что собрал какое-то мелкое приложение на Rust, так и не продемонстрировав мощь метапакетной системы для сборки произвольного кода.

Ну потому что Rust и так умеет собирать в этот target, ничего нового не произошло.

А надо это продемонстрировать на каком-нибудь интересном примере, когда в rust приложение подмешивается что-то интересное, помимо экосистемы rust.

https://t.iss.one/itpgchannel/1330
https://t.iss.one/itpgchannel/1195

Даже мои эксперименты с wasm бывали более содержательны - https://t.iss.one/itpgchannel/1189

Или, например, вот - https://t.iss.one/itpgchannel/1553

#harfbuzz #AI

Нам тут подсказывают с задних рядов, что, не прошло и года (нет, реально, всего несколько дней не хватило), как умельцы положили в этот шейпер на #wasm какую-то там LLM модель - https://fuglede.github.io/llama.ttf/

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

Тем не менее, размах мысли завораживает!

#WASM #WebAssembly #WASI #blob #wazero

Тема с компиляцией C/Rust кода в wasm (https://t.iss.one/itpgchannel/1553), и использование его через wazero в go, кажется, пошла в массы:

https://github.com/ncruces/go-sqlite3

Очень разумный способ использовать зависимости на С/Rust без CGO, и без соответствующих проблем.

Правда, так как в go отсутствует вменяемая система сборки, sqlite3, собранный в wasm, прикопали прямо в репке - https://github.com/ncruces/go-sqlite3/blob/main/embed/sqlite3.wasm. Как я это нашел? Ну, так как я знаю, что go build не в состоянии выразить такую зависимость, то просто взял, и нашел.

Ай-яй-яй, никогда такого не было (https://t.iss.one/itpgchannel/1281), и вот, опять, нам тащат вирусню в проект добавили очередной supply chain attack.

#WASM #WebAssembly #WASI #blob

https://github.com/wasilibs/go-yamllint

Технология движется семимильными шагами!

На этот раз yamllint, запускается через тот же #wazero, только это не Rust, а вполне себе настоящий интерпретатор питона, собранный под #WASI.

(спасибо нашим читателям за наводку!)

Будни #bootstrap #blob

Оказалось, что там есть версия rollup, которая собрана в бинарь, но под #wasm, и потому может быть исполнена на любом хосте с nodejs.

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

Заодно выяснилось, что там прикопан бинарник от https://github.com/evanw/esbuild, а это уже серьезнее, потому что он на go, статически слинкован, и я даже не заметил, что он у меня запускался в процессе сборки.

Изящно заменил его на свой - https://github.com/pg83/ix/blob/main/pkgs/bin/rqbit/ix.sh#L47-L52

Мораль?

Решил инвестировать больше времени в автоматическое выбрасывание из скачанных исходников всякого бинарного треша!

https://creston.blog/wasm-will-replace-containers/

Скорее бы уже, потому что я все еще имею мечту про "правильно" устроенный Linux:

* Все компилируется в #WASI #WebAssembly

* Есть одна большая WebAssembly VM, в которую статически слинкованы "системные" библиотеки - API opengl/vulkan, драйвера для opengl/vulkan (mesa), libc, ABI ядра, fontconfig, harfbuzz, и так далее - все, что имеет стабильный ABI.

* Все пользовательские приложения - тонкие клиенты к этой VM. В них нет свох кешей шейдеров, своих кешей шрифтов, и так далее, все это живет в VM.

* WebAssembly VM - идеальный клей между языками и рантаймами (CGO - тихий ужас, а вот загрузить Rust модуль в #wazero - это заебись. Линковать mesa в каждую программму - тихий ужас, а вот иметь OpenGL как "тонкий клиент" в VM - очень даже хорошо).

https://www.phoronix.com/news/libinput-Lua-Plugin-System

https://who-t.blogspot.com/2025/05/libinput-and-lua-plugins.html

"The libinput input handling library that's used by both X11 and Wayland based environments on the Linux desktop is preparing to introduce a Lua-based plug-in system. Via Lua scripts it will be possible to modify evdev input events / input device behavior to deal with quirky/broken input devices and better workaround other problems that aren't currently easily addressable"

Слушайте, а вот это прямо очень "вкусно".

Для Linux есть довольно прилично демонов, которые умеют remap событий от evdev.

Хороший список есть у Arch - https://wiki.archlinux.org/title/Input_remap_utilities.

Я перепробовал literally весь этот список, и у всех программ из него есть одна неприятная особенность - они очень opinionated относительно того, что умеют делать. Вот есть у них свой кастомный DSL, и то, что он может выразить - то может, а все, что за рамками - идет лесом. Остановился, кстати, на https://github.com/KarsMulder/evsieve.

Поэтому такой вот micro framework прямо в libinput - это прямо очень, очень хорошо.

Можно было и #WASM, тем более, он уже линкуется в любое GUI приложение, вместе с #harfbuzz (https://t.iss.one/itpgchannel/1201), но lua тоже заебись:

"So why Lua? Because it's very easy to sandbox. I very explicitly did not want the plugins to be a side-channel to get into the internals of libinput - specifically no IO access to anything. This ruled out using C (or anything that's a .so file, really) because those would run a) in the address space of the compositor and b) be unrestricted in what they can do. Lua solves this easily. And, as a nice side-effect, it's also very easy to write plugins in"