https://github.com/faster-cpython/ideas/blob/main/3.13/README.md
https://github.com/faster-cpython/ideas/blob/main/3.12/README.md

#fast_python

Закончил читать два фундаментальных (если считать ссылки) текста про грядущие оптимизации python.

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

Oh, fun fact - Гвидо, похоже, отодвинули от процесса - https://github.com/faster-cpython/ideas/commits/main

Совпадение? Хм...

https://blog.rust-lang.org/2023/06/20/introducing-leadership-council.html

Тут вот пишут, что распустили Core Team, и завели новый.

Я не очень слежу за подобного рода событиями, скажите, а там по существу что-то меняется, или так, стулья переставляют?

#wasm #bootstrap

После написания того текста я решил, что мне катастрофически не хватает какого-то решения для поддержки WebAssembly - как для сборки в него, так и выполнения.

Потому что раз всем нужно, то и мне тоже нужно!

Вот, теперь все есть:

pg# cat qw.c 
int f(int a, int b) {
    return a + b;
}
pg# /ix/store/.../bin/clang \
    --target=wasm32 \
    -nostdlib \
    -Wl,--no-entry \
    -Wl,--export-all \
    -O2 \
    -o qw.wasm \
    ./qw.c 
pg# /ix/store/.../bin/iwasm \
    --repl ./qw.wasm 
webassembly> f 1 2
0x3:i32
webassembly> 

Я завел интерпретатор из https://github.com/bytecodealliance/wasm-micro-runtime, llvm jit из него же, тулчейны из https://github.com/WebAssembly/binaryen, https://github.com/WebAssembly/wabt, ну а clang давно уже умеет в wasm.

На самом деле, я немножко мухлюю, потому что надо еще собрать wasm libc (поверх WASI - https://github.com/WebAssembly/wasi-libc), но, в целом, уже все работает, причем без всяких там rust и emscripten.

https://ohadravid.github.io/posts/2023-03-rusty-python/

Неожиданно годный текст про оптимизацию питона через переписывание кода на Rust.

Неожиданно - потому что заголовок совершенно кликбейтный, "python", "rust", "в 100 раз", короче, все, как я люблю. Да и задача, мягко говоря, выбрана странно - чуваки написали кусок пайплайна 3d рендера на python, причем кусок, который непосредственно обрабатывал геометрию. А потом героически оптимизировали этот кусок, хотя ответ, кажется, всем очевиден - не надо обрабатывать геометрию на python.

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

Довольно подробно расписано использование биндингов из Rust в Python + NumPy.

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

https://lwn.net/Articles/935592/

RH закрывает доступ к исходникам, из которых собирает RHEL. По подписке они продолжают быть доступны, все честно.

В комментариях срач, коллеги никак не могут договориться, кто же больше паразитирует на open source:

* RH, переупаковывая и продавая чужой труд
* Alma/Rocky линуксы, пересобирающие RHEL из исходников, ранее доступных всем
* Oracle ...

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

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

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

Продолжение истории про Red Hat.

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

Из интересного:

"Для клиентов компания Red Hat оставила возможность загрузки кода srpm-пакетов RHEL через закрытый раздел сайта, на котором действует дополнительное пользовательское соглашение (EULA), запрещающее редистрибуцию RHEL. Использование в AlmaLinux и Rocky Linux srpm-пакетов, загруженных через клиентский портал Red Hat, сопряжено с юридическими рисками."

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

Science and Technology links (June 25 2023)

1. Women in highly religious relationships report the highest levels of relationship quality. 2. US politics is largely divided into two parties (Republicans and Democrats). People who are affiliated with the Republicans have many more kids. 3. The Antartic ice shelves gained 661 gigaton of ice over the past decade. 4. A low protein diet increases mortality among older men. 5. Consuming magnesium may preserve your brain, especially if you are a woman. 6. A third of the planet around common stars in our galaxy could be in the habitable zone. 7. Taurine (a supplement) might keep you young. It works, in some ways, in different animals. McGaunn et al. (2023) make a case for human beings, but they do not have much in the way of quality clinical trials. 8. Older people often lose their thymus, a gland that plays an important role in your immune system. Sandstedt et al. report that about two-third of their middle-age subjects had lost entirely the thymus (complete…

https://lemire.me/blog/2023/06/25/science-and-technology-links-june-25-2023/

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 решили эти проблемы.