https://www.phoronix.com/news/Go-1.21-RC

#perf

Меня расстраивают игры с PGO в Go.

Go сейчас - sweet point между скоростью компиляции и качеством генерируемого кода. Это, кстати, одна из тех причин, по которым мне НРАВИТСЯ писать на Go. Не просто "ок", а именно нравится - вспоминается детство, безумно быстрый borland pascal (безумно - потому что он рожал код моментально на моем pentium 75, а не на современных многоядерных монстрах), и это ощущение "потока", когда от изменения строчки кода до ее проверки проходит нисколько времени.

Но, как это обычно бывает, у разрабов Go закончились идеи на тему "как же ускорять получающийся код, не замедляя компилятор", а оплачивать ипотеку как-то надо, вот и пошли в дело не самые приятные идеи.

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

По слухам, Путин с Лукашенко хотят запретить Rust. Ждем, надеемся.

https://xn--r1a.website/rasstriga/10295

#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 - это, кажется, что-то странное, скорее всего, я его криво собрал.

https://www.redhat.com/en/blog/red-hats-commitment-open-source-response-gitcentosorg-changes

Мерзотный текст от RH, с "объяснением" происходящего.

Мерзотный - потому что он, в лучших традициях, пытается одновременно объяснить два взаимоисключающих параграфа:

* "Нам нужны деньги, чтобы платить ЗП разрабам" (а еще акционерам, но про это не сказано), "поэтому нам приходится делать так, чтобы нашу работу было сложно повторить".

* "Нуачотакова? Вот исходники, все выложено, делайте с ними, чо хотите". И опять же, четко не сказано, что собрать из этих исходников RHEL, не зная конкретные ревизии, невозможно, потому что смотри предыдущий параграф.

#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

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