https://www.phoronix.com/scan.php?page=news_item&px=LibreOffice-WASM-2022 #wasm #WASI

Писал про WASM в Firefox. Мне кажется, что за WASM, конечно, большое будущее(а все же помнят, что я мастер предсказывать уже произошедшие события, да?):

* Оно достаточно вменяемое в среднем. Без встроенного GC там, например.

* Насколько я понял, WASM bytecode сохраняет более полный граф выполнения программы(условно говоря, не goto label, а if - then - else) в сериализованном виде. Я недавно читал статью(к сожалению не сохранил, если вдруг есть под рукой - скиньте, pls), что такая структура позволяет процессору лучше оптимизировать выполнение кода.

* Ну и самая мякотка - легион JS-разрабов, которые затащут этот WASM везде. И, знаете ли, в какой-то момент может показаться очень заманчивым начать исполнять браузер и Electron на реальном железе.

Короче, вот вам прогноз - на горизонте в 15 лет мы увидим соревнование WASM и RISC-V, в реальном железе(я вот только не очень понял, насколько WASM memory safe по дефолту, поэтому в реальном железе может быть немного другой вариант).

Хотя, конечно, я часто бываю черезчур оптимистичным.

https://medium.com/@losfair/a-comparison-between-webassembly-and-risc-v-e8fb9d37e6cc

То, что WASM заточено на JIT, IMHO, как раз будет только в плюс, потому что процессоры все больше и больше становятся похожи на hi-perf VM.

Почему это не произошло с Java, или на мобильных платформах уже? А все заметили, что сейчас случился ренессанс процессоростроения, и процы в железе под разные задачи не отливает разве что ленивый?

———
Я иногда люблю чем-нить упороться, а теперь у меня для этого есть новая игрушка - мой Mix.

Я его строю не только как пакетный менеджер, но и как (мета) систему сборки, построенную по enterprise лекалам. Например: #ix #gold #dev_shell #ix_run

* кросс-компиляция
* из этого следует возможность собрать произвольный код с произвольным набором флагов и опций.

То есть, я могу построить всю программу целиком, включая библиотеки, с такими фичами, как:

* санитайзеры
* debug/release
* разные optimization levels

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

Для всяких bazel/buck/ya/etc это очевидные свойства, но для OSS систем это достаточно свежая вещь.

Короче, мне всегда было интересно, что будет, если там разные программы пособирать с С++ garbage collector в качестве аллокатора.

* Quake работает like a charm, без лагов, памяти жрет раза в полтора больше.
* Браузер не запускается, какие-то проблемы в выделении drm буффера.

Кстати, gc не такая уж и глупость, оно помогает для того, чтобы заставить работать какую-нить бажную программу с use after free, а у меня такие есть(например, M4 некоторых версий).

#wasm #wasi #bootstrap

Я таки собрал какое-то приложение в WASM формате, под платформу WASI (специально постоянно про это упоминаю, потому что набор команд (WASM) и доступные вызовы в систему (WASI) - это разные вещи).

К сожалению, пока ничего не заработало.

Сначало оно ругалось на неподдерживаемые ассемблерные команды:

pg# /ix/.../wasm-interp \
    /ix/.../bin/base64 
0002080: error: unexpected opcode: 0xfe 0x48

Я дизассемблировал этот файл, и понял, что речь идет про

0020bf: fe 48 02 00 i32.atomic.rmw.cmpxchg 2 0

Попробовал включить в интерпретаторе поддержку тредов, но:

pg# /ix/.../bin/wasm-interp \
    --enable-all \
    /ix/.../bin/base64 
error initializing module:
    invalid import "wasi_snapshot_preview1.args_get"

Оказалось, что интерпретатор собран без поддержки WASI. Пересобрал, но:

pg# /ix/.../bin/wasm-interp \
    --enable-all --wasi \
    /ix/.../bin/base64 
unknown wasi API import:
    `sched_yield`

Тут я пока сдался, потому что WTF?

#wasm #wasi #bootstrap #ix_run

Ну, вот, после пары сегфолтов, я это дело таки завел:

pg# ./ix run \
  bin/b64 --target=wasi32 \
  bld/sh \
  bin/iwasm/fast/er \
  -- \
  iwasm --fast-jit \
  '$(command -v base64)'

  b64      (Base64 Encode/Decode)    Bob Trower 2001/08/03 
           (C) Copr Bob Trower 1986-2015     Version 0.94R 
  Purpose: This program is a simple utility that implements
           Base64 Content-Transfer-Encoding (RFC1113).
           Use -h option for additional help.

https://wasi.dev/ мне кажется черезчур сложным для реализации. Ну и там пока очень мало чего, чтобы стать полноценным OS API - там нет всяких манипуляций с FS, сигналов, треды в зачаточном состоянии, процессов тоже нет.

Жду, когда запилят WASM + Linux ABI. Кажется, это не должно быть очень сложным - нужно запилить тонкую прослойку, которая бы проксировала из контекста интерпретатора в контекст системы всего шесть функций - syscall0, ..., syscall5 (это Linux ABI), а поверх этого сконпелять musl в виде libc.

Это не так гранулярно, зато можно очень быстро получить связку WASM jit + Linux, в качестве target platform.

#wasm #wasi #bootstrap

Однажды начав, бывает сложно остановиться.

Собрал еще 4 wasm рантайма:

https://github.com/wasmx/fizzy
https://github.com/wasm3/wasm3
https://github.com/WasmEdge/WasmEdge
https://github.com/tetratelabs/wazero

Из них только wasmedge оказался способен выполнить мою тестовую программу:

pg# ./ix run bin/b64 \
    --target=wasi32 \
    bld/sh \
    bin/wasm/edge \
    -- \
    wasmedge --enable-all \
    '$(command -v base64)'

  b64      (Base64 Encode/Decode)    Bob Trower 2001/08/03 
           (C) Copr Bob Trower 1986-2015     Version 0.94R 
  Purpose: This program is a simple utility that implements
           Base64 Content-Transfer-Encoding (RFC1113).
           Use -h option for additional help.
pg#

Вообще, их, конечно, больше - https://github.com/appcypher/awesome-wasm-runtimes, но остальные или выглядят заброшенными, или написаны на странных языках, типа Python, или Rust.

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

https://go.dev/blog/wasi

Вот, в продолжение темы "#WASI as api boundary".

Go поддержал компиляцию в #WASI.

Я, в связи с этим, хочу поспекулировать на тему "WebAssembly as language boundary".

Получается, что программа, однажды скомпилированная в WebAssembly, может использовать рантаймы очень разной природы - на Rust, C/C++, JS, whatever.

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

Это, в целом, заманчиво, потому что пляски с ffi и системным ABI, которые, сами по себе, являются локальными оптимизациями под процессорные архитектуры 80-90х годов прошлого века, утомили. Нужно задавать передаваемые типы, а не исполнять 1000-страничные мануалы, где написано, когда и как что может быть передано в EAX.

https://www.neversaw.us/2023/09/04/understanding-wasm/part3/you-are-here/

А вот еще один, довольно водянистый, текст про WebAssembly/#WASI.

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

Но вот еще одна забавная мысль, которую я оттуда почерпнул - "WebAssembly as security boundary".

Что это значит? Это значит, что достаточно продвинутая WASM VM может эмулировать fork(), и процессы, без поддержки операционной системы, и без переключения контекстов, соответственно.

Идея это не очень новая (кто сказал https://en.wikipedia.org/wiki/Singularity_(operating_system) ?), но, кажется, в случае WebAssembly, мы близки к этому, как никогда ранее.

Будни #bootstrap, #cross

У меня уже довольно давно была поддержка кросс-компиляции с любого host на любой linux, и на всякие нишевые платформы типа #WASI

Вот, добавил darwin-{amr64,x86_64} - https://github.com/pg83/ix/commit/85c66407c092677519f45ee55b265bc272759ad5.

В коммите всякие мелочи, типа {% if linux %} на зависимости, которые не собираются под darwin, типа libsigsegv, libbsd, и так далее.

Так как у меня cross compile даже для host == target, ничего особо сложного в этом не было, все заработало из коробки.

Почему я не сделал это раньше?

Потому что все это время я думал, как половчее попиздить macos sdk!

Компания Apple, как и MS, не очень поощряет сборку не на своих OS/железе. У них это написано в лицензии.

Поэтому есть такой небезызвестный https://github.com/phracker/MacOSX-SDKs - смотреть можно, трогать пользоваться, кажется, нельзя.

При этом, я решал следующие задачи:

* Рандомный васян, скачав #IX, должен "из коробки" уметь собрать любую программулю под macos. Украдет он при этом что-то, или нет, - не мои проблемы.

* Если это запускается на родной платформе для macos, то, по умолчанию, надо брать установленные в систему SDK, и ничего не воровать.

* Если этот код запускается в каком-то частном контуре, то должна быть возможность указать на url, по которому будет лежать цельнопижженый легальный (с точки зрения владельца этого контура) слепок macos sdk. Например, он его купил, но за пределы контура распространять не может.

Соответственно, для васяна я качаю SDK с инторнетов, для host == target сборки даю возможность использовать родную SDK, ну а злые корпорации пусть в своем контуре используют то, что считают нужным, это не мое дело.

Все это я сделал моим любимым способом "dispatch по настройкам во все более специализированный таргет" - https://github.com/pg83/ix/blob/main/pkgs/lib/darwin/c/ix.sh#L3-L12

И сразу добавил нужные мне таргеты в мой CI - https://github.com/pg83/ix/blob/main/pkgs/set/ci/unwrap/ix.sh#L8-L9, это было совсем просто!

С windows sdk все будет, кажется, существенно хуже, потому что найти прямые ссылки на даже "серые" их версии у меня не получается. Везде всратый windows installer, который даже cabextract не берет. А выкладывать пижженый контент от своего имени мне бы не хотелось.

#cross, будни #bootstrap

Продолжаю тему кросс-компиляции в macos, https://t.iss.one/itpgchannel/1444

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

Вот, например, вам бинарник dosbox, статически слинкованный под macos-arm64, с linux-x86_64 host.

Без зависимостей от всяких всратых libSDL.dylib/libSDL2.dylib/etc.

(понятное дело, что он не полностью статически слинкован, это невозможно под macos, потому что там поверхность взаимодействия с системой - 100500 closed source фреймворков)

Мне интересно, будут ли с этим бинарником какие-то проблемы, связанные с таким необычным способом сборки, позапускайте (malware not included).

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 в браузере!

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

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

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

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 - очень даже хорошо).