vladkens.me

Хотел программу для диктовки, а вышло три библиотеки

2026-11-11T00:00:00+00:00

Поменял MacBook M2 в старом корпусе на новый Air M5 без вентилятора. При переходе на новый компьютер хочется нового и чистого. Поэтому вместо того, чтобы тащить за собой все старые программы и настройки, решил поискать альтернативы полегче и нативнее. Например, VS Code заменил на Zed, Chrome — на Helium.

Для работы с агентами пользовался программой для диктовки Handy, но мне жутко не нравилось, что она написана на Tauri, хотелось чего-то нативного. Попросил агента найти альтернативу. Но ничего из того, что он нашёл, мне не подходило. Решил написать сам.

Вдохновившись X, где люди сейчас переписывают всё на GPUI Kit, решил попробовать тоже. Тем более автор Handy выделил движок распознавания речи отдельно в transcribe.cpp, поэтому оценил задачу как лёгкую, тем более с помощью агентов.

Неделя 1. Выбор GUI и прототипы

Собственно, взял GPUI Kit, распиаренный в X, и с агентами быстро сделал первую версию интерфейса. Получилось неплохо, приложение с открытым окном занимало около 80 МБ оперативной памяти. Но компиляция была жутко долгой, частично из-за самого GPUI Kit, частично из-за линковки transcribe.cpp, которая шла около минуты при каждой пересборке.

Ещё не понравилось, что GPUI Kit тащит с собой больше 400 зависимостей, прямо как в Node.js. Кто знает, какой вирус может оказаться внутри? Кроме того, GPUI от Zed не является готовой библиотекой со стабильными релизами, поэтому GPUI Kit сидит на dev-версии из репозитория Zed, и API может поменяться в любой момент. Отдельная проблема — интеграция с системой, вроде иконки в трее или нативного контекстного меню. В GPUI Kit этого нет, и всё это нужно писать самому.

Решил посмотреть, какие есть альтернативы в Rust-инфраструктуре. Помню, что ещё в доагентскую эпоху экспериментировал с egui для интерфейсов, и от него остались хорошие впечатления. Он и правда оказался быстрее и легче по памяти, да и крейтов тянул меньше. Но все нативные интеграции всё равно нужно писать самому, а компоненты сильно кастомизировать, чтобы они выглядели приятно.

Отдельно попробовал нативные контролы: Rust-биндинги к системным UI-библиотекам — AppKit на macOS, Win32 на Windows и GTK на Linux. Тоже вдохновился проектом из X — mygo: в нём нативные десктопные интерфейсы делают на Go. Но по сути пришлось писать гигантскую кучу кода интеграции и повторять это минимум три раза. Вид приложения получался нативным под каждую платформу, но настолько разным, что некоторые фичи нельзя было нормально выразить, несмотря на то, что программа для диктовки — это буквально меню настроек, список моделей и история.

Всё это время больше всего раздражала пересборка: при каждом запуске приходилось ждать под минуту, пока линкуется transcribe.cpp. Ну и вообще непонятно, почему в моём Rust-тулчейне должен быть C++. Решил посмотреть, что там внутри происходит.

Неделя 2. Свой движок распознавания речи

Внутри transcribe.cpp оказался ggml, где под каждую видеокарту написан свой код для Metal, Vulkan и CUDA, и для сборки каждого нужны свои инструменты. В Rust есть wgpu, где шейдеры пишутся один раз на WGSL и работают на любой видеокарте, а всё собирается обычным cargo build.

Стало любопытно, получится ли запустить на WGSL хотя бы одну модель, хотя мыслей что-то переписывать ещё не было. Взял GigaAM v3, которой пользуюсь чаще всего, и сделал на ней небольшое демо. На удивление, агенту легко удалось писать шейдерный код, и результаты получились сравнимые с оригинальной библиотекой.

Тут появился спортивный интерес. Вспомнил, как занимался оптимизацией быстрого счёта на кривой secp256k1 в ecloop и оптимизацией RIPEMD-160, и начал смотреть дальше. Первой была GigaAM v3 e2e RNN-T, модель с пунктуацией и заглавными буквами. Кроме неё решил добавить и другие модели того же семейства, чтобы понять, насколько это сложно. Они отличаются декодером: CTC распознаёт каждый кусочек звука отдельно, а RNN-T учитывает ещё и свой предыдущий текст, поэтому точнее, но медленнее. И у каждой есть версия с пунктуацией (e2e) и без неё.

Для диктовки использую два языка: русский и английский. И раз первый вышло добавить легко, подумал, что со вторым тоже не должно возникнуть проблем. Для английского хорошо подходит Parakeet v2 от NVIDIA, она точная и быстрая. Но когда начал её добавлять, оказалось, что модели бывают разных архитектур и для каждой нужно писать свой код вычислений.

Сами модели брал уже упакованными в GGUF от автора transcribe.cpp. Как оказалось, GGUF хранит только веса и метаинформацию о модели: название архитектуры, размеры слоёв, словарь. Самих вычислений в файле нет, и их нужно писать самому. Этим формат и отличается от TensorFlow или Core ML от Apple, где в файле модели описан граф операций, а среда просто его исполняет.

В общем, пришлось сидеть и разбираться, читать, смотреть видео на YouTube о том, как устроены и работают модели распознавания речи. Если коротко, длинное аудио режется на куски (у Whisper, например, это окна по 30 секунд). Каждый кусок через быстрое преобразование Фурье (FFT) превращается в спектрограмму (какие частоты звучат в каждый момент). Спектрограмму получает энкодер (стопка слоёв нейросети, в которых в основном перемножаются матрицы) и превращает её в последовательность векторов. Декодер читает их и шаг за шагом выдаёт токены (кусочки слов), из которых собирается текст. Основная работа — матричные умножения в слоях энкодера, их и считает видеокарта.

Разобравшись с тем, как это работает, добавил поддержку Parakeet v2. Первую версию за ночь написал Codex, но вышло грязно, так что выкинул её и переписал начисто с Claude Code. В итоге получилась довольно быстрая программа speech-to-text, которая на моих тестах обгоняла transcribe.cpp. И раз уж вошёл в раж, сразу добавил Parakeet v3, мультиязычную модель из того же семейства (почти ничего не пришлось дописывать). А следом и Whisper как эталонную модель, с которой удобно сравнивать остальные.

Отличий у Parakeet от GigaAM хватает. Модель крупнее (24 слоя против 16, и каждый шире), ужимает звук вдвое сильнее (один вектор на 80 мс вместо 40) и иначе отмечает, в какой момент что прозвучало. Но главное в декодере (TDT): вместе с очередным токеном он предсказывает, сколько следующих отрезков звука можно пропустить.

И раз программа в целом так хорошо получалась, решил выложить её отдельным проектом в стиле ollama. Назвал её wavo, типа от WAV, и имя было свободное. Тем более что раньше уже бывала нужда в локальной расшифровке аудио, а ничего хорошего из терминала для этой задачи не было. Пробовал whisper.cpp, но это медленно и неудобно (его нужно компилировать самому, а аудио резать на куски вручную).

Перед публикацией решил причесать код. Сборку всё ещё тормозил крейт rustfft, а раз wavo могут подключать как библиотеку, эта задержка досталась бы каждому, кто его собирает. Поэтому, разобравшись с причиной, написал свой FFT под конкретную задачу. Вышло 176 строк кода против 55 тысяч в rustfft, а пересборка ускорилась с 11,9 до 2,1 секунды (сам крейт хороший, просто рассчитан на все случаи, а нужен был один).

Финальный этап перед публикацией — тестирование. Хорошо, что под рукой несколько маков, Linux на N100 и x86 с видеокартой GeForce и хорошим процессором. Поручил агенту прогнать финальные тесты и сравнить скорость с другими библиотеками. На маках моя библиотека рвала всех по скорости без вопросов (до сих пор в шоке, что это так легко получилось). Но на Windows с видеокартой NVIDIA был большой провал. Снова пришлось разбираться, и оказалось, что есть такая штука, как flash attention.

Attention — это место в модели, где каждый вектор сравнивается со всеми остальными в том же куске аудио (у Whisper это 1500 векторов на 30 секунд, то есть больше двух миллионов сравнений в каждом слое). Обычный код записывает всю эту таблицу в память видеокарты и потом читает обратно. Flash attention считает то же самое небольшими порциями в быстрой памяти рядом с ядрами видеокарты и таблицу целиком не хранит.

На маках агент сделал такие шейдеры ещё раньше, но под матричные блоки Apple (аппаратное ускорение). У NVIDIA эти блоки другого размера, поэтому там wavo считал всё стандартным кодом. После добавления шейдеров под матричные блоки NVIDIA wavo на Windows догнал, а где-то и перегнал transcribe.cpp (короткую запись Whisper turbo теперь распознаёт за 201 мс против 226 у конкурента, а было 637).

Все замеры делал на RTX 4060, а на AMD Radeon не тестировал вовсе. Поэтому буду рад результатам с других видеокарт в issues.

Ещё во время тестов нашёл, что на M5 wgpu использует только старые матричные блоки. В M5 в каждом ядре видеокарты появился нейроускоритель, который умножает матрицы втрое быстрее (0,60 мс против 1,89 мс). Но добраться до него можно только через Metal 4, а wgpu его пока не знает. Обошёл это отдельным шейдером на Metal только для M5 и завёл issue в wgpu.

Ещё научил wavo работать на Neural Engine (отдельной части чипов Apple для нейросетей), но это уже другая история. В общем, в конце провёл финальное сравнение Parakeet v3 на английском против других движков, и цифры получились впечатляющими.

Движок	На чём	Фраза 5 с	Час записи
wavo	Neural Engine	0,12 с	200×
FluidAudio	Neural Engine	0,13 с	175×
wavo	GPU	0,14 с	160×
transcribe.cpp	GPU	0,12 с	107×
parakeet.cpp	GPU	0,77 с	90×
parakeet-mlx	GPU	0,63 с	61×
sherpa-onnx	CPU	0,83 с	39×

В таблице время на фразу в 5 секунд и во сколько раз быстрее реального времени распознаётся часовая запись (MacBook Pro на M5). На русском с GigaAM v3 разрыв похожий (wavo в 330 раз быстрее реального времени, transcribe.cpp в 262).

Неделя 3. Свой рендер

Пока шла работа над wavo, другой агент в фоне экспериментировал с библиотекой интерфейса. Раз во всех подходах всё равно приходилось руками писать много обёрток для связи с операционной системой, решил, что можно написать и рендер самому. К тому же был опыт с интерфейсами в видеоиграх, так что задача казалась несложной.

Давно являюсь поклонником Sublime Text и особенно Sublime Merge и их подхода к интерфейсу. Подумал, раз авторы этих программ и авторы редактора Zed смогли написать свой UI-фреймворк, то и я, вооружившись агентом, смогу. Вооружившись утилитами strings и nm, посмотрели, какие системные функции использует Sublime Merge, и по ним восстановили идею, она была интересной ;)

Текст там рисует сама система (CoreText на macOS, DirectWrite на Windows, Pango на Linux), поэтому он везде выглядит нативно, в отличие, например, от egui, который рисует глифы своими средствами. Каждый глиф система рисует один раз, он кладётся в кэш, и дальше на экран идут уже готовые глифы из кэша. Так же, системными, сделаны и контекстные меню (в GPUI Kit их по умолчанию рисуют сами).

В общем, получился такой себе Франкенштейн — по краям системные вещи, а в центре, как начинка в сэндвиче, моя библиотека, которая раскладывает элементы по окну и собирает из них компоненты.

Для рендеринга используется immediate mode (кадр каждый раз собирается заново, без сложной системы событий). В обычных приложениях не так много интерактивности, и условное окно настроек не нужно перерисовывать 60/120 раз в секунду. К тому же кадр пересобирается, только когда что-то изменилось, а в простое окно ничего не рисует.

Рисовать сам кадр решил на CPU. Это самый простой код, и работает он везде одинаково — без шейдеров, драйверов и прочей лабуды, которую нужно интегрировать, а потом ещё и тестировать. Готовый кадр отдаётся системе в обычный 2D-вывод окна, и для приложения без сложных анимаций скорости хватает с запасом.

3D-ускорение тянет за собой дополнительные библиотеки, и программа начинает есть больше памяти (на Windows простое окно с D3D11 занимает 27 МБ вместо 5,1). Но если понадобится, его всегда можно добавить потом.

Сам рендер получился где-то в 3 тысячи строк кода на Rust, и агент быстро накидал на нём базовые компоненты (ещё около 6 тысяч строк). Всё работало, и казалось, что дело почти сделано.

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

Теперь стало понятно, почему в доагентскую эпоху было так мало GUI-фреймворков. Сложность совсем не в том, чтобы написать рендер и систему компонентов, а в том, чтобы связать всё это на разных платформах и чтобы оно работало. Каждая кроссплатформенная фича легко может занимать несколько тысяч строк на три системы:

окна (открыть, перетаскивать и рисовать в них): 5 тысяч строк;
текстовые поля и IME: 4 тысячи;
трей, горячие клавиши и автозапуск: 7 тысяч;
доступность на macOS: 3 тысячи;
нативное контекстное меню: 2 тысячи.

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

Например, контекстное меню можно нарисовать и своим рендером, так сделано в GPUI в Zed. Но смотрится это стрёмно, а главное, такое меню не может выйти за рамки окна. Раньше даже не задумывался об этом, но, начав писать, понял, что это важно. Sublime Merge это умеет, за что его и хвалю.

Ожидаемо, самой большой болью оказался Linux. Если на macOS и Windows всё делается через один системный API, то на Linux это грёбаный зоопарк. Сначала пытался отдельно рисовать на X11 и Wayland, чтобы программа была максимально оптимизирована, но количество кода росло по экспоненте. Поэтому пошёл на компромисс и взял GTK 3, который есть почти на всех дистрибутивах, так же сделано и в Sublime Merge.

Библиотеку назвал nimbo. Простое окно со счётчиком на ней тянет 14 крейтов на macOS, 5 на Windows и 3 на Linux (почти всё это биндинги к системе, вроде objc2 на macOS и windows-sys на Windows), собирается с нуля за 11 секунд, а бинарник весит 1,3 МБ. Для сравнения тот же счётчик на других фреймворках (число крейтов на каждой системе, чистая релизная сборка на M2 и размер бинарника):

	macOS	Windows	Linux	Сборка	Бинарник
nimbo	14	5	3	11 с	1,3 МБ
iced	152	159	237	59 с	10,9 МБ
Tauri¹	217	223	265	64 с	9,9 МБ
Xilem	157	177	257	65 с	12,2 МБ
egui	177	178	279	74 с	14,3 МБ
Slint	248	244	345	84 с	12,5 МБ
GPUI	300	270	322	86 с	8,6 МБ
GPUI Kit	411	395	518	144 с	19,4 МБ

¹ Плюс системный WebView, который в бинарник не входит.

В эпоху персонального софта и бесконечных взломов для такого рода программ хотелось бы иметь свою основу и не зависеть от чужих фреймворков. Поэтому решил довести nimbo до ума. Первого релиза пока нет, сейчас доделываю API, поэтому не хватает времени делать крутые видео в X. Но если кому-то нужно что-то минимальное на Rust, велком.

Библиотеку строю в три слоя. Снизу общий API для системных вещей (окна, трей, контекстное меню и тому подобное), чтобы из кода приложения не касаться их в принципе. Над ним headless-компоненты (поведение без оформления), под которые можно сделать любой дизайн. И сверху базовый дизайн в стиле системных контролов. Ориентир для API библиотеки — SwiftUI.

Неделя 4. Релиз: подпись, упаковка, обновления

Программа готова и протестирована, осталось только выпустить релиз. Но и тут всё оказалось не так просто. Проблем набралось три: подпись, упаковка и автообновление, и на них ушла последняя неделя.

Подпись

В последних версиях macOS и Windows приложения без подписи просто не запускаются. На Windows проще: SmartScreen при первом запуске покажет предупреждение, с ним можно согласиться, и приложение запустится. А на macOS с неподписанного приложения нужно руками снимать карантин командой /usr/bin/xattr -dr com.apple.quarantine /Applications/Wavo.app, что рядовой пользователь вряд ли будет делать.

Пришлось раскошелиться на 99 долларов в год и заплатить Apple. Форма оплаты у них при этом из начала нулевых: данные карты вводишь руками, а деньги Apple списывает сама когда-нибудь потом. Списание в итоге упало на 3-D Secure, пришлось временно понижать защиту на карте и писать в поддержку, чтобы повторили оплату, и вся история растянулась на несколько дней. Такого давно уже не припомню.

Упаковка

Программа для трёх систем — значит, и установщики нужны на все три: на macOS стандартное решение — DMG, на Windows — setup.exe, который ставит программу, обычно на NSIS, а на Linux — AppImage и .deb-пакет. Форматов на Linux на самом деле больше, но пока выбрал эти два.

Сначала показалось, что это легко сделать Python-скриптом, что и поручил агенту. Требование было одно: сборка и подпись разделены. У этапа сборки, который скачивает и компилирует чужой код, доступа к ключам подписи быть не должно, а второй этап только ставит подпись на готовые файлы.

Скрипт быстро вырос почти до двух тысяч строк. Тут я удивился и пошёл искать готовые решения, ведь за столько лет кто-то наверняка решил эту задачу. Некоторые решения нашлись (Velopack, cargo-packager и упаковщик Tauri), но у всех свои проблемы. Одни не умеют отделять сборку от подписи, а самое неприятное, что почти никто не умеет работать на одной машине (DMG и подпись для macOS делают только на Mac, deb и AppImage только на Linux, а для Windows нужен ещё NSIS). Velopack умеет собрать всё сразу, но только на Mac. По-моему, это безумие, упаковка и подпись должны работать на одном компьютере, причём желательно на любом.

Поизучал чужие репозитории, и из того, что видел, нормально это сделано только у Mozilla. Firefox они упаковывают на Linux, даже DMG для macOS, но лютыми хаками. Для DMG у них свой форк C-библиотеки libdmg-hfsplus, у которого нет готовых сборок, и в CI его собирают прямо из репозитория по коммиту. Чтобы использовать его у себя, пришлось бы вытаскивать артефакт из чужого билда без версии, а этого не хотелось. Ну и раз есть агент, то снова поручил эту работу ему.

Изначально хотел сделать это частью nimbo, но потом понял, что это совершенно отдельная программа, и вынес её в отдельный крейт shipo.

Главная идея shipo в том, что все установщики собираются на любой машине, хоть на Linux. Всё, что есть только на одной системе (hdiutil на macOS, makensis для Windows, пакеты apt на Linux), заменено своим кодом, а остальные утилиты скачиваются с фиксированной версией и хешем.

Для macOS shipo сам пишет DMG вместе с файловой системой HFS+ по спецификации Apple (даже с таблицами Unicode, по которым HFS+ нормализует имена файлов) и .DS_Store, который раскладывает в окне иконку приложения и ярлык на /Applications. Иконку .icns он тоже собирает сам, без sips и iconutil. Подпись и нотаризация вне Mac идут через rcodesign и сервис нотаризации Apple.

Для Windows установщик тоже свой. Это заранее собранный маленький setup.exe на Rust с пустой меткой внутри. Упаковщик подменяет в exe приложения иконку, версию и манифест, сжимает файлы в один архив, дописывает его в конец setup.exe и прописывает в метку, где этот архив лежит. Деинсталлятор — это тот же setup.exe, только без файлов.

Для Linux AppImage (готовый рантайм, к которому дописан образ squashfs с приложением) и deb собираются прямо в памяти.

Автообновление

Третья вещь к упаковке по факту отношения не имеет, но заниматься пришлось и ей. На macOS многие программы обновляются через Sparkle, но он работает только на macOS. Под Windows есть похожий по идее WinSparkle, но это другая библиотека. Хотелось чего-то одного для всех систем, но и тут ничего не нашёл. Решил, что сборка и обновление — близкие вещи и могут жить в одном крейте, поэтому сделал их вместе.

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

У shipo это один текстовый файл update.txt в последнем релизе на GitHub:

version 1.2.0
notes https://github.com/me/hello/releases/tag/v1.2.0
macos-aarch64 394788 <sha512> https://github.com/me/hello/releases/download/v1.2.0/Hello-v1.2.0-macos-aarch64.dmg
windows-x86_64 285930 <sha512> https://github.com/me/hello/releases/download/v1.2.0/Hello-v1.2.0-windows-x64-setup.exe
linux-x86_64 412204 <sha512> https://github.com/me/hello/releases/download/v1.2.0/Hello-v1.2.0-linux-x86_64.AppImage
sig <signature>

В нём версия, ссылка на заметки к релизу, по строке на каждую платформу (размер, хеш SHA-512 и адрес файла) и в конце подпись Ed25519 всего, что выше. Отдельный сервер обновлений не нужен, приложение просто качает файл из последнего релиза на GitHub по постоянной ссылке (releases/latest/download/update.txt).

Приложение сверяет скачанный файл по размеру и хешу. Ключей подписи в приложении два, рабочий и запасной: если рабочий утечёт, следующий релиз подписывается запасным.

Для обновления используется тот же установщик, что и для первой установки. На macOS библиотека подключает DMG, копирует из него приложение и заменяет старое. На Windows запускает setup.exe без окна, на Linux заменяет файл AppImage.

Для HTTP в shipo нет отдельной библиотеки, вместо неё три короткие обёртки над системными (NSURLSession на macOS, WinHTTP на Windows, libcurl на Linux). Поэтому зависимостей у апдейтера мало: проверка подписи, ошибки и биндинги к системе.

Так за неделю появился shipo, около 12 тысяч строк кода: примерно 10 тысяч на упаковщик (вместе с заготовкой setup.exe) и 2,4 тысячи на библиотеку, которая попадает в приложение. Упаковщик в нём собирает установщики для всех трёх систем на одной машине, а апдейтер добавляет в приложение всего 8–15 крейтов в зависимости от системы (у Velopack и cargo-packager их больше сотни). По итогу правильно зарелизить приложение и настроить CI оказалось сложнее, чем написать рендер интерфейса.

Итого

Программа на пару дней превратилась в месяц работы. За это время набралось около 850 коммитов и 167 тысяч строк изменений (вместе с прототипами и тем, что потом выкинул). Работа с агентами заняла около 90 активных часов и 3,7 млрд токенов, по ценам API это примерно 2,7 тысячи долларов (цифры примерные, часть логов агентов потерялась).

Код в основном писал Claude Opus 5.5, ревью делала GPT-6 Astra. Ещё около 390 ревью сделал Copilot в GitHub, пока я не словил лимит. Графику и картинки рисовал Codex.

На этом работа не закончилась. Чтобы о программе узнал кто-то, кроме родственников и друзей, про неё нужно написать на Reddit, в X и прочих местах, и это тоже отдельная большая работа. Пока ей занимался, нашёл множество похожих программ, и, если бы видел их изначально, наверняка бы не занимался своей программой в принципе. Но что уже есть, то есть. В принципе, вышел свой кросс-платформенный стек, который, надеюсь, буду переиспользовать для других вещей.

Ещё раз все программы из статьи:

Wavo: локальная диктовка для macOS, Windows и Linux;
wavo: CLI и Rust-крейт для распознавания речи в стиле ollama;
nimbo: нативная UI-библиотека почти без зависимостей;
shipo: установщики и автообновление для трёх систем с одной машины.

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

Как следить за лимитами в Codex и Claude Code

2026-05-21T00:00:00+00:00

Продолжаю настраивать coding-агенты под себя. В прошлый раз был про процесс работы с ними, теперь мелкая деталь — контроль лимитов через statusline.

Я пользуюсь двумя coding-агентами: Codex и Claude Code. Оба меня устраивают, и я спокойно переключаюсь между ними: иногда потому, что в одном заканчиваются лимиты, иногда потому, что просто веду разные задачи в разных клиентах. Основным у меня стал Claude Code — именно там раньше всего появились skills, MCP и прочая рабочая обвязка. За это время вокруг него накопилось много настроек, и далеко не всё я перенёс в Codex. Как это нормально автоматизировать, я тоже не понял. Если кто-то уже решал такую синхронизацию между Claude Code и Codex, напишите в комментариях — буду рад ссылке или совету.

После того как месяц-полтора назад ввели лимиты, стало неудобно постоянно проверять их руками через /status. С контекстом та же история: чтобы понять, сколько ещё осталось до автокомпакта, нужно отдельно дёргать /context. Само по себе это несложно, но делать это постоянно быстро надоедает. При этом хотелось заранее видеть, когда лимит или контекст уже близко, чтобы успеть что-то сохранить руками. После автокомпакта модель у меня часто тупеет и забывает важные факты. Поэтому я полез смотреть, как это вообще можно отслеживать, и выяснил, что у обоих клиентов есть statusline. По умолчанию он и там и там довольно минималистичный и показывает в основном только текущую модель.

В Codex statusline настраивается адекватно. Достаточно написать /statusline и в интерактивном UI выбрать, что показывать. Дальше эти настройки сохраняются в ~/.codex/config.toml.

Я для себя выбрал такой формат:

gpt-5.4 medium · ~/Code/blog · Context 73% left · 5h 93% · weekly 92% · 258K window · 1.2M used

В Codex нельзя задать полностью свой формат строки. Можно только выбрать набор готовых блоков и их порядок.

В конфиге это выглядит так:

[tui]
status_line = ["model-with-reasoning", "current-dir", "context-remaining", "five-hour-limit", "weekly-limit", "context-window-size", "used-tokens"]
theme = "catppuccin-macchiato"

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

Что касается claude-code, у него тоже есть команда /statusline. Но вместо интерактивного меню с набором блоков, как в Codex, здесь подошли иначе — по-агентски: робот пытается прочитать мои bash / zsh / fish-конфиги и на их основе сгенерировать statusline.

Очевидно, я не стал давать ему доступ к файлам, потому что не хочу отправлять свои конфиги в Anthropic. Да и не очень понимаю, зачем они им, если на GitHub и так полно dotfiles-репозиториев.

В ~/.claude/settings.json можно указать команду, которая запускается при каждом обновлении statusline. Выглядит это так:

{
  // ...
  "statusLine": {
    "type": "command",
    "command": "~/.claude/statusline.sh",
    "padding": 0,
  },
}

Здесь command — это просто скрипт, который Claude Code будет запускать при обновлении statusline. На GitHub можно найти много разных реализаций. Например, такие безумные решения: sirmalloc/ccstatusline, Owloops/claude-powerline, Haleclipse/CCometixLine, hagan/claudia-statusline, felipeelias/claude-statusline. Безумными я их называю потому, что в эпоху, когда очередной npm-пакет ломают чуть ли не каждый день, ставить дополнительный софт через npm ради настолько простой задачи кажется странной идеей.

Но идею у них позаимствовать можно. Команда запускается при каждом обновлении статуса, в stdin приходит JSON, который можно распарсить и отобразить как угодно. Документация по доступным полям: Claude Code statusline docs

В общем, в statusline приходит примерно такой набор данных:

{
  // shortened example; see docs for the full schema
  "session_id": "<session-id>",
  "transcript_path": "/Users/<user>/.claude/projects/<project>/<session-id>.jsonl",
  "cwd": "/Users/user/Code/blog",
  "session_name": "<session-name>",
  "model": { "id": "claude-sonnet-4-6", "display_name": "Sonnet 4.6" },
  "workspace": { "current_dir": "/Users/user/Code/blog" },
  "version": "2.1.126",
  "output_style": { "name": "default" },
  "context_window": {
    "total_input_tokens": 433,
    "total_output_tokens": 492,
    "context_window_size": 200000,
    "current_usage": {
      "input_tokens": 1,
      "output_tokens": 92,
      "cache_creation_input_tokens": 299,
      "cache_read_input_tokens": 14201,
    },
    "used_percentage": 7,
    "remaining_percentage": 93,
  },
  "exceeds_200k_tokens": false,
  "fast_mode": false,
  "effort": { "level": "high" },
  "thinking": { "enabled": true },
  "rate_limits": {
    "five_hour": { "used_percentage": 62, "resets_at": 1779296400 },
    "seven_day": { "used_percentage": 22, "resets_at": 1779750000 },
  },
}

Вообще для кастомизации терминала я использую starship.rs. У них даже есть интеграция с Claude Code: Statusline for Claude Code. Но блоков для часовых лимитов там нет — после того как их добавили в Claude, starship так и не обновился. Issue на GitHub висит: starship/starship#7441. Насколько я понял, автор репозитория куда-то пропал, и уже несколько месяцев в проекте почти ничего не происходит.

Так что я просто попросил Claude написать bash-скрипт, который выведет строку в том же формате, что в Codex. Вышло что-то такое:

#!/usr/bin/env bash
set -euo pipefail

input="$(cat)"
get() { jq -r "$1" <<<"$input"; }

fmt_tokens() {
  awk -v n="$1" 'BEGIN {
    if      (n >= 1000000) printf "%.1fM", n / 1000000
    else if (n >= 1000)    printf "%.0fK", n / 1000
    else                   printf "%d",    n
  }'
}

model="$(get '.model.display_name')"
dir="$(get '.workspace.current_dir')"
dir="${dir/#"$HOME"/\~}"

context_remaining="$(get '(.context_window.remaining_percentage // 100)')% left"
five_hour="$(get '(100 - .rate_limits.five_hour.used_percentage) | round')%"
weekly="$(get '(100 - .rate_limits.seven_day.used_percentage) | round')%"
window="$(fmt_tokens "$(get '.context_window.context_window_size')")"
used="$(fmt_tokens "$(get '.context_window.context_window_size * .context_window.used_percentage / 100')")"

printf '%s · %s · Context %s · 5h %s · weekly %s · %s window · %s used\n' \
  "$model" "$dir" "$context_remaining" "$five_hour" "$weekly" "$window" "$used"

В итоге оба клиента начинают выглядеть одинаково:

Единственный косяк, который я заметил в Claude Code: при открытии терминала statusline не показывается сразу в новых сессиях. Появляется только после первого взаимодействия с чатом (можно вызвать вручную через Cmd+Shift).

На этом всё. На настройку statusline и написание заметки ушло около трёх часов.

Spec-Driven Development на практике

2026-05-20T00:00:00+00:00

Попробовал два инструмента для Spec-Driven Development на своём pet project — delta-farmer (51 файл, 12k строк кода). Сравнивал spec-kit и cc-thingz: прогнал каждый через два кейса — аналитику по безопасности и обычный coding.

Инструменты

spec-kit (github) — open source тулкит для Spec-Driven Development. Помогает сосредоточиться на product scenarios и предсказуемом результате вместо vibe coding с нуля; работает поверх разных coding-агентов, генерирует под каждый этап отдельные файлы.

cc-thingz (github) — набор skills для Claude Code, который ставится через plugins / marketplace api. По сути это уже готовый workflow внутри Claude, а не отдельная внешняя обвязка над разными агентами.

Setup, workflow и артефакты

spec-kit задуман как более универсальная штука под разных агентов, но за это платишь отдельной CLI-обвязкой, своими шаблонами и своей структурой файлов. Flow у него устроен как последовательность отдельных команд: /speckit-specify -> /speckit-plan -> /speckit-tasks -> /speckit-implement, плюс отдельно /speckit-clarify для уточнения спеки. На одну задачу он создаёт несколько файлов.

Отдельная проблема spec-kit — папка .specify. Это его внутренняя служебная структура, в которой он хранит часть своих данных и метаданных по workflow. Непонятно, что из этого нужно добавлять в git, а что не нужно. В документации я не нашёл ни явных рекомендаций по этому поводу, ни внятных best practices для командной работы.

spec-kit также вставляет ссылку на текущую задачу прямо в CLAUDE.md / AGENTS.md. Любая новая Claude-сессия сразу видит её и работает в контексте этой задачи — просто поговорить по проекту или параллельно спланировать что-то другое уже не выйдет.

cc-thingz в этом смысле проще: он сразу завязан на Claude Code и ставится в его экосистему как набор skills. Pipeline у него тоже фиксированный: /brainstorm -> /plan:make -> /plan:review -> /plan:exec, но ощущается проще. На одну задачу у него получается один файл.

Планирование

У spec-kit планирование разбито на несколько отдельных команд. Сначала запускается /speckit-specify <task-description>: инструмент анализирует поставленную задачу, смотрит на исходный код, иногда задаёт уточняющие вопросы, на которые отвечать нужно в формате quiz в чат-режиме — буквально отправить букву A / B / C или свой вариант ответа (без интерактива, как в plan-mode).

После этого spec-kit пишет файлы на диск, и дальше начинается ручное ревью. Нужно открыть эти файлы, прочитать их и понять, насколько адекватно агент описал задачу. Если что-то не нравится, нужно написать об этом в чате — инструмент генерирует обновлённую версию.

Следующий этап — /speckit-plan. Агент по сгенерированному ранее описанию пытается написать техническую постановку задачи. Процесс тот же: генерация, ревью, комментарии — и так до удовлетворительного результата.

Финальная команда планирования — /speckit-tasks. Она раскладывает основную задачу на подзадачи. Формат работы с агентом остаётся прежним. По сути весь flow у spec-kit устроен одинаково на каждом этапе: запускается команда, инструмент пишет файлы на диск, а дальше их приходится валидировать вручную.

В итоге внутри specs/<task-name>/ собирается структура файлов вроде spec.md, plan.md, tasks.md, research.md, data-model.md, checklists/requirements.md и прочего. Каждый следующий этап дописывает туда новые файлы или обновляет старые, поэтому на одну задачу быстро нарастает большой объём текста, который нужно читать и валидировать руками.

Также есть /speckit-clarify — побрейнштормить решение перед написанием технической задачи и перед декомпозицией.

У cc-thingz процесс выглядит по-другому. Всё начинается с /brainstorm: после описания задачи инструмент задаёт вопросы в интерактивном режиме. Там можно выбрать готовый вариант ответа или ввести свой, то есть это не просто переписка в чате, а работа через меню с готовыми опциями (как в plan-mode).

После /brainstorm агент сразу предлагает следующие шаги: продолжить планирование, проверить результат вручную, отдать его на авторевью или сохранить. Если выбрать авторевью, дальше подключаются другие агенты, которые сами проверяют план, ищут в нём проблемы и вносят правки. За счёт этого значительная часть ревью встроена прямо в flow, ещё до ручной проверки.

Дальше можно либо сразу продолжить работу из того же окна, либо сохранить файл и вернуться к нему позже через /plan:make <file>. На этом этапе агент дописывает в файл технический план и список подзадач. Всё это собирается в один Markdown-файл в docs/tasks/, и новая информация просто дописывается в конец.

После этого агент снова предлагает варианты действий в интерактивном режиме: можно ещё раз прогнать план через ревью, сохранить его или сразу перейти к реализации. Когда работа по задаче заканчивается, файл перемещается в docs/tasks/completed. За счёт того, что всё живёт в одном файле, здесь проще смотреть diff, проще читать изменения и не нужно каждый раз думать, какой файл открыть.

Выполнение задач

У spec-kit реализация запускается командой /speckit-implement specs/<spec>, после чего агент начинает работать над задачей и писать код.

У cc-thingz реализация запускается через /plan:exec. Её можно запустить с файлом в новой сессии или сразу продолжить после этапа планирования. Дальше агент последовательно идёт по подзадачам из плана, пишет код, по ходу работы дописывает тесты под свою реализацию и сам же их запускает для проверки результата, а в конце прогоняет всё через дополнительное ревью другим агентом.

Задача 1. Supply chain hardening

Python-проект для автоматизированной торговли, распространяется через git clone + uv run. Зависимости описаны в pyproject.toml через >=-диапазоны, uv.lock не закоммичен, поэтому при клонировании пользователи получают непонятные версии с PyPI без каких-либо гарантий.

Нужно было понять, как правильно защитить такой проект от supply chain проблем, без внешних сервисов типа Renovate или Dependabot. Какие файлы коммитить, как пинить версии и как потом обновлять их (примером взять то, как это реализовано в pnpm), как быть уверен что все депсы безопасны перед релизом. Плюс был дан референс на best practices.

Планирование

Сначала я дал обоим инструментам одно и то же описание задачи и запустил первый проход, чтобы они подумали над ней. У cc-thingz это был /brainstorm, у spec-kit — /speckit-specify.

Дальше предложенное агентом решение прогнал через агента-критика. У spec-kit для этого есть /speckit-clarify, а cc-thingz после первого прохода сам предложил три варианта: закоммитить план, сделать ревью самому или отдать ревью другому агенту. Выбрал последний вариант.

У cc-thingz в итоге получился понятный план. Задача свелась к четырём изменениям: закоммитить uv.lock — это даёт воспроизводимые установки и SHA256-верификацию; добавить exclude-newer = "7 days" — блокирует пакеты, опубликованные меньше 7 дней назад (защита от timing attacks в духе LiteLLM); включить only-binary = [":all:"] — запрещает выполнение setup.py при установке, только wheels; добавить uv audit для CVE-сканирования перед релизами.

У spec-kit на этапе /speckit-clarify агент начал задавать странные вопросы в стиле "что делать, если uv audit запущен в offline среде – пропускать PR или нет".

Он также зачем-то предложил отправлять нотификации про CVE через telegram-интеграцию в коде. Эта интеграция используется для trade start / stop, то есть робот увидел кусок кода, не понял, для чего он нужен, и смешал в одну кучу внутреннюю логику приложения и внешний security tooling.

Плюс, хотя проект на uv, он все равно тащил решения под pip из статьи, вместо того чтобы использовать нормальные uv-штуки. Например, зачем-то предлагал uv run pip-audit, хотя у uv уже есть свой uv audit.

Дальше в режиме планирования он разложил на 21 подзадачу, то есть буквально каждый чих оформил как отдельный пункт.

Реализация

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

Результат cc-thingz получился понятным, его легко читать и не страшно использовать дальше. spec-kit использовал непонятные пакеты, поэтому результат даже не запускался. Работает ли то, что он сделал — не проверял: результату не доверял и запускать не стал.

Задача 2. Реальная coding-задача

Описание задачи (580 слов, 5 кб): что нужно сделать, где брать данные и как проверить результат. Конкретные файлы намеренно не называл — всё на откуп разработчику, как в реальной жизни.

Коротко суть: есть три источника данных. Общая история сделок пользователя (1), история сделок провайдера по всем пользователям (2) и последние несколько дней сделок у провайдера по конкретному пользователю (3). Нужно скачать источник 2 и 3, отфильтровать по ним источник 1, закешировать это на диск и встроить в вывод программы вместо того, что в ней сейчас (по сути там просто источник 1).

Планирование

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

cc-thingz задал несколько нормальных вопросов по реализации, после чего предложил план. Дальше он дал два варианта: проверить план самому или отдать на проверку другому агенту. Выбрал второй вариант — получил файл на ревью, внёс несколько мелких правок и закоммитил план. Получился один файл на 10.6 Кб, 158 строк, 1479 слов и 7 задач. Плюс он спросил про вещи, которые я упустил в описании задачи. Например, как хранить кеш на диске и как выглядят типы данных. В этой задаче баг как раз был в том, что два источника по-разному представляют одни и те же данные: в одном месте 1000, в другом 1000.0, и напрямую это нормально не маппится.

spec-kit никаких дополнительных вопросов сам не задавал. После трех команд (specify / plan / tasks) уже лежала целая пачка файлов, которые нужно было читать и проверять: 40.5 Кб, 737 строк, 4761 слово и 13 задач. Читать это тяжело даже один раз, не говоря о том, что эти файлы меняются в процессе ревью.

Реализация

cc-thingz запускался не напрямую, а через ralphex: https://github.com/umputun/ralphex. По сути это Claude / Codex в YOLO mode в Docker. В моём случае команда была такая: ralphex --serve docs/plans/20260515-onyx-fills-filtering.md. Работает оно долго: на полный проход уходит час-полтора.

spec-kit запускался через /speckit-implement 002 (где 002 — номер задачи) в новой сессии.

Когда ralphex уже делал последнюю задачу, у меня закончился пяти-часовой лимит. Над какой задачей в этот момент работал spec-kit, так и не понял, потому что свои файлы во время работы он не обновлял. У cc-thingz в этом смысле было проще: он создавал коммит после каждого изменения, поэтому полная история осталась.

Возобновить работу в обоих инструментах можно по-разному. У spec-kit это обычная Claude-сессия: когда лимит сбросится, можно писать дальше в том же окне. Либо её можно закрыть и открыть заново через --resume. У ralphex иначе: его можно вызвать заново с тем же файлом задачи, и он сам понимает, где в прошлый раз остановился, потому что по ходу работы расставляет чекбоксы в todo-листе. Поэтому он продолжает выполнение с последней точки остановки. Понятно, что без ralphex — cc-thingz тоже работает как обычная Claude-сессия.

Результат

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

У cc-thingz проблема была в том, что агент не уточнил у меня всю важную структуру данных на этапе планирования и не сходил в источник данных, чтобы взять себе sample, хотя я писал, что эти данные публичные. В итоге он интерпретировал поле Time как timestamp, а не как строку в ISO-формате, из-за чего данные не парселись. Других проблем с запуском не было, но данные считались неправильно. После нескольких десятков минут дебага в отдельной Claude-сессии (не знаю, как подключиться к логам ralphex, поэтому открыл новую) выяснилось, что робот вызвал API с неверными параметрами. Из-за этого часть данных не удавалось правильно отфильтровать по источнику.

У spec-kit на этапе запуска были другие ошибки: он решил, что отчет нужно считать за 2025 год, хотя я явно указывал, что считать нужно с 1 января 2026 года. В итоге он очень долго скачивал данные и влетел в rate limit. Дальше была ошибка с lock/unlock при записи в файлы. Данные он решил хранить отдельным файлом на каждую дату, хотя я просил сохранять это в один файл и дописывать его при обновлении. После запуска — та же проблема с неправильными цифрами: пришлось идти в чат, включать дебажные логи, разбираться и исправлять.

Оба написали тесты. У cc-thingz они проходят. У spec-kit — нет, то есть он их не запускал и корректность сгенерированного кода не проверил.

Посмотреть на код, task-файлы и организацию изменений можно в диффах: spec-kit (11 файлов, 1206 строк) и cc-thingz (9 файлов, 760 строк). У spec-kit изменений больше, но значительная часть — это его собственные spec-файлы, а не код. cc-thingz поработал плотнее с кодовой базой.

Итог

Перед тем как тестировать оба инструмента, я прогнал вторую задачу самостоятельно — просто в режиме диалога с Claude в edit-режиме, без какой-либо спеки. Нормальной постановки задачи у меня тогда ещё не было: я просто не понимал, где брать данные и как они устроены. Поэтому весь разбор шёл прямо в чате — дебажили вместе с агентом, смотрели что приходит из API, разбирались в структуре. На это ушло часа два-три.

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

Мой финальный отзыв:

spec-kit — инструмент с понятной идеей, но неудобный в работе. Генерирует много файлов, которые нужно читать и ревьюить вручную. На планирование ушло около часа, потом ещё час работал агент, потом ещё час на разбор и доработку того, что не заработало. Тесты написал, но не запустил. Артефактов оставил больше, чем кода. Для несложной задачи это избыточно.

cc-thingz — работать с ним проще. Один файл, интерактивный режим, встроенное ревью. Тот же ритм по времени: час на спеку, час на реализацию, час на доработку. Тесты написал и запустил. Ошибки были, но причина понятна — агент не уточнил структуру данных заранее и не взял sample из публичного API. Результату можно доверять больше, хотя идеально тоже не вышло.

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

Полные диффы по обеим задачам: spec-kit, cc-thingz.

Несколько мыслей напоследок

Работать с агентами в таком режиме в целом удобно, но когнитивная нагрузка оказывается довольно высокой. Нужно заранее грамотно сформулировать задачу, внимательно прочитать всё, что агент для себя написал на этапе планирования, и убедиться, что он учёл все важные аспекты. Если это сделано хорошо, дальше он работает достаточно стабильно. Теоретически в это время можно писать спеку для следующей задачи — но пока это скорее иллюзия, чем реальный параллелизм.

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

cc-thingz с ralphex стоит рассматривать для действительно простых задач. Расписал задачу в файл, запустил — и оно само. Для этого сценария это выглядит как реально рабочая вещь. Но у приложения тогда должна быть хорошая тестируемость и понятная структура.

Итоги 2025: тихий год и погружение в крипту

2025-12-31T00:00:00+00:00

Заканчивается очередной год, и по своей новой традиции хотелось бы подбить некоторые итоги текстом. В целом для меня год вышел пассивным: не помню, чтобы я планировал большие дела, но тем не менее предыдущие годы были для меня активнее в творческом плане и не только (open-source, новые навыки и т. д.).

OpenSource

В этом году я не выпустил ни одного нового open-source проекта, хотя некоторые наработки у меня были. Старые проекты потихоньку поддерживаю, но тоже без особого энтузиазма (для некоторых проектов это и была основная идея — стабильность).

Детально по главным проектам:

twscrape (мой самый популярный проект) — постоянно нужно бороться с новыми палками от X;
apigen-ts — в ближайшем будущем codegen нужно будет переписать на templates в связи с тем, что TypeScript переписали на Go, и есть вероятность, что AST-примитивы пропадут из пакета typescript в npm. Также лично для меня актуальность проекта немного снизилась из-за использования tRPC/NextJS в основном стеке, но для non-JS backend это до сих пор must-have;
macmon — тоже довольно сложно поддерживать, потому что Apple слишком часто выпускает новые процессоры и в разных конфигурациях, поэтому не всегда есть возможность получить нужное железо для тестов. Искал online-сервисы для доступа к «голому» железу по SSH на время (модель, как у VPS), но ничего актуального не нашёл;
ecloop — добавил в библиотеку SIMD-оптимизацию для SHA-256 и RMD-160. Думаю, это была моя самая интересная задача в этом году. Хотел поиграться с CUDA, даже заказал для этого компьютер, но так и не воспользовался этим. А что касается самой крипты, то я занялся дегенством (об этом позже).

Публичные проекты на GitHub — всего 92 коммита, 79 закрытых issues, 11 созданных релизов и более 1k полученных звёзд.

UPD: Я вспомнил, что в конце 2024 / начале 2025 занимался badges.ws на Rust. Это выглядело как довольно простая задача, но вылилось в несколько месяцев работы и дебагинга разных API. В общем, наверное, нужно было вовремя бросить проект, но я этого не сделал и дотянул его до релиза — ценой своего желания запускать новые проекты. Какой из этого сделать вывод, я не знаю.

Blog

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

Проблемы Zola:

странный язык шаблонов, в котором не хватает каких-то вещей, а issues висят годами;
GPT плохо понимают этот шаблонизатор — реально каждый раз, когда нужно сделать изменение, даже нагуглить сложно как сделать;
отсутствие гибкости в навигации страниц и организации файлов (я не могу сложить файлы блога так, как мне удобно, и нужно следовать системе движка);
сломанные редиректы в тексте — Zola не понимает относительных ссылок в тексте (все ссылки нужно делать относительно навигации сайта), поэтому нельзя удобно писать и работать с блогом локально: делать линковку между своими статьями и быть уверенным, что все ссылки актуальны. Сейчас мне приходится решать это отдельным скриптом.

В качестве engine мне бы хотелось что-то, что использует JSX в качестве шаблонизатора, tailwindcss из коробки, не имеет проблем Zola с навигацией и линковкой, и является простым и стабильным решением. В целом в эту категорию подходит Astro, на который я пробовал обновить блог, но и у него есть ряд своих проблем:

дубликация логики и сложность выбора между форматами .astro и .jsx;
отсутствие нормальной интеграции MD/MDX (любая кастомизация — это CSS-классы, а не нормальное переопределение рендеринга markdown-тегов через JSX-элементы);
отсутствие генерации feed в формате Atom из коробки (поддерживается только RSS), то есть это нужно делать вручную.

В общем, я тестово обновил блог на Astro, но так и не отправил это в релиз, потому что решение мне показалось сложным. А блог — это такая вещь, которую можно не трогать месяцами, а когда нужно потрогать, хочется сразу понимать, что и как, а не гуглить/жипитить решение.

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

Много текста про блог вышло. В общем, мне бы хотелось писать больше, меньше отвлекаясь на проблемы. Из идеального решения на данный момент, как мне видится, — это формат MD/MDX с возможностью переопределять элементы. Возможно, кто-то знает готовые хорошие решения? (ну или это идея для проекта на Bun)

Skills

Если в предыдущие годы я разбирался и практиковался в DevOps, Rust, Go, LLM, NestJS/NextJS и прочих вещах, то этот год вышел нейтральным. Я навскидку не скажу, что нового учил в этом году. Наверное, главное изменение в рабочем окружении — это переход с iTerm2 на WezTerm. Причиной стало запихивание LLM в терминал и дыра в безопасности.

В целом весь год было боязно обновлять софт: сейчас многое пишется с AI, и качество релизов стало откровенно слабым. Например:

я пользуюсь Chrome с 2009 года, и в этом году впервые увидел баги рендеринга, креши и т. п.;
поиск Google несколько месяцев был сломан, и им было пофиг (если написать запрос с ошибкой, поиск предлагает правильный вариант, его можно нажать, и он подставится в поисковое поле, но если затем кликнуть в поле, возвращается старый вариант с ошибкой — возможно, кому-то это кажется мелким косяком, но это мой популярный use case);
на YouTube несколько дней после релиза нового плеера звук нельзя было сделать выше 60% через интерфейс: ползунок просто не двигался. Я не понимаю, как можно релизить то, что даже не тестировалось в продакшене;
куча таких же мелких багов, которые портят UX.

Короче, что-то в мире разработки пошло не так. Оттого и обновляться страшно, потому что непонятно, как тебе в очередной раз сломают рабочий flow. Моя любимая программа — Sublime Merge: обновления там чисто косметические, пару раз в год.

Crypto aka Degen

Отдельно стоит рассказать про это направление. В январе я делал небольшой проект по бриджу ERC-20 / SPL-токенов между сетями Eth / Sol. В это же время Trump выпустил свой Meme Coin: те, кто был инсайдером или просто быстрым, хорошо на этом заработали, остальные остались в минусе. Мне стало интересно, чем живёт крипта в целом — не техническая часть, а именно community.

В итоге я подписался на разные чаты и т. п. с информацией по теме (но это реально большой поток, часто мусорной информации). Позже нашёл DoubleTop community, где сейчас состою и регулярно общаюсь.

В общем, вторую половину года я средне активно занимался криптой — пробовал разные направления, чтобы понять, что тут да как. Пока мой опыт такой: заработать в крипте можно, но это реально сложно и требует много времени и внимания. Потерять — сильно легче. Иксов на депозит нет, но проценты могут быть.

Кейсы в которых участвовал:

Sale Fleek на Coinlist — rekt −70%, команда просто заскамила;
Sale Enso на Coinlist — хорошо, +70%;
Sale Plasma — x10 на аллокацию, но сложно было занести и лок средств на 3 месяца;
Sale Pump.fun — x2 за 3 дня, но, как всегда, были нюансы. Мне повезло часть занести через сайт, а CEX сделали refund;
Almanak на Legion — rekt −50%. В целом нормальный был проект, но команда затянула с выходом и вышла на плохом рынке в минус. Я забыл, что участвовал в этом сейле, и не продал токены вовремя;
Farm Paradex — x2 на траты. Ожидали, что проект выйдет летом, но потом релиз перенесли на неопределённое время. Это был мой первый проект под ретродроп, поэтому мой пыл поутих к фарму других проектов. В ноябре–декабре команда Paradex добавила опцию перевода XP, и появилась возможность продать поинты на OTC, чем я и воспользовался;
Farm Lighter — тут реально много иксов. Свои поинты я получил в основном за hedge-позиции, а целенаправленно фармил мало. Учитывая как плох сейчас рынок, проект буквальне сделал всем подарок на Новый год;
Binance Alpha — простая ежедневная активность, где нужно было крутить торговые объёмы на Binance. С аккаунта выходило по $300-400 в месяц, но сложно было мультить;
Sales on BuidlPad — площадка хорошо и стабильно кормила половину года, легко было мультить, но и аккаунты часто не пускали. Нужно было много ликвидности, чтобы участвовать, потому что аллокации давали маленькие. В среднем все сейлы вышли x2 на траты;
Flash crash 10 Oct — вся крипта жёстко упала за пару часов и до сих пор не вернулась на прежние уровни. У меня не было perp-позиций, поэтому тут повезло, но были loans в USDT/USDC под криптоактивы, которые ликвидировало;
Spot-позиции (рынок плохой): BNB +30%, ETH +20%, SOL −20%, HYPE −40%.

Конечно, самих кейсов было больше — я перечислил основные закрытия. В целом в крипте зарабатывать можно, но это реально сложная и системная работа. Крипторынок жив несколько месяцев в году, когда проходит столько ивентов, что нет возможности везде поучаствовать (не хватает капитала и сил/времени). А большую часть года на рынке ничего не происходит — в это время люди идут работать в McDonald's. Это как раз период, чтобы фармить ретродропы, но это реально сложная работа: за свои действия и потраченные деньги результат будет только через полгода-год, и мне такое психологически сложно.

Сейчас мета — PerpDex (Paradex / Lighter / Aster / Extended / Pacifica.fi / Ethereal / Trade.xyz / etc) и opinion markets (Polymarket / Opinion / Limitless / etc).

Самая сложная часть в крипте для меня — это подбить балансы и понять, я в плюсе или в минусе (реально работа бухгалтера сложная). Примерно для себя год закрыл с тем же, что у меня и было, хотя в моменте депозит доходил до +50%. Тут важно сказать что все что касается крипты нужно делать по РК (риск-контроль) – я для себя выделил бюджет с которым я эсперементирую.

Короче, всё это большая тема, и, наверное, мне стоит рассказать об этом отдельно.

Здоровье

Пока жив — и это хорошо.

В этом году бросил курить — очень рад этому, чувствую себя лучше и снизил шансы разных раков. В целом бросать несложно: я посмотрел несколько видео на YouTube, чтобы понимать, что меня ждёт и какие «приколы» будет придумывать мозг, чтобы уговорить меня снова взять сигарету. Первые недели три постоянно думаешь о курении, потом это проходит. Основное «думание» связано не с самим процессом курения, а с тем, как был устроен быт — типа отдохнуть, посмотреть в окно, попить кофе, перекурить. Сейчас периодически возникает пятиминутное желание перекура в виде флешбеков.

Стал делать стабильную зарядку — минимум пару раз в неделю (веду статистику в Sheets). Без этого реально чувствую себя хуже: сложно работать, когда болит спина и т. п. Периодически делаю замеры тела, и, наверное, главное изменение — бицепс +2 см.

Досуг

Приобрёл Xbox, чтобы расслабляться играя (у меня в прошлом был PlayStation 4, поэтому хотел попробовать другую платформу). Попробовал довольно много игр (через Game Pass) — до этого несколько лет играл мало. Из того, что понравилось:

Clair Obscur: Expedition 33 — очевидная игра года, 100% стоит её пройти: насладиться историей, артом, музыкой и боёвкой.
Mafia: Definitive Edition — переиздание классики, немного упростили. Миссия с гонками всё ещё требует несколько десятков траев — и это хорошо.
Indiana Jones and the Great Circle — хорошая игра, приятно было исследовать Рим и египетские пирамиды, разгадывать местные загадки. Кулачные бои тоже довольно забавные, а огнестрельное оружие брать в руки и не хочется.
Doom: The Dark Ages — легендарная серия про демонов. Я играл только в Doom 1 и Doom 3, всю новую линейку пропустил. Решил попробовать с The Dark Ages. В целом первая половина игры интересная: крутые локации, постоянно открывается новое оружие и т. п. Но вторая половина душная — все локации превращаются в серую кишку. Еще прикольные миссии на роботе-титане.
Assassin's Creed Mirage — изначально казалась очередным ассасином, но чем больше играл, тем лучше она становилась. Остались хорошие воспоминания о тёплом Багдаде. По-моему, это одна из сильнейших игр серии. Что радует — она короткая. Играл до недавнего DLC, сейчас говорят, что стало ещё лучше.
Escape from Duckov — игра-мем в жанре экстракшн. Полностью не проходил, потому что долгая, но попробовать, чтобы понять смысл жанра, стоит. Затягивающая.
Lies of P — первый соулслайк (раньше только пробовал Sekiro, но там для меня ад). Понравилась: боссы сносные для обычного человека, и есть много способов их победить (теневой подсос, метательные банки с жидкостями). Простой и интересный сюжет, хотя к концу немного растянули время прохождения.

Прочие медиа, которые запомнились.

Фильмы/сериалы: Fly Me to the Moon (2024), The Fighting Sullivans (1944), American Beauty (1999), The Naked Gun (2025), How to Steal a Million (1966), Once Upon a Time... in Hollywood (2019), Bugonia (2025), Аватар: Путь воды (2022).

Музыка: Sabrina Carpenter, The Velvet Sundown (да, AI-slop), Alice in Chains.

Книги: особо не читал, из последнего — Ионеско «Носороги».

Всех с Новым годом! 🎉

Оптимизация RIPEMD-160 используя ARM Neon и не только

2025-05-08T00:00:00+00:00

У меня есть хобби-проект — ecloop — "калькулятор" Bitcoin-ключей, предназначенный для поиска Bitcoin Puzzles, проверки brain wallets и тому подобного. Математические шансы нахождения приватного ключа от использованного адреса стремятся к нулю. Эта программа мне интересна как набор трюков над эллиптической кривой (secp256k1) и как способ попрактиковаться в программировании, близком к процессору (быстрая 256-битная арифметика), поэтому я периодически продолжаю её развивать.

Для вычисления Bitcoin-адреса из private key нужно выполнить несколько операций:

вычислить точку на эллиптической кривой (Public key) — P = G * PrivKey
посчитать SHA256 от PubKey: (P.y % 2 == 0 ? 0x02 : 0x03) + P.x
посчитать RMD160 от полученного SHA256

В результате получится так называемый hash160, который затем кодируется в Bitcoin-адрес с использованием base58 или bech32.

Как бы ни были медленны операции на эллиптической кривой, самая медленная часть генерации адреса — это вычисление RMD160. Фактически, оно занимает примерно половину времени работы (SHA256 на современных процессорах имеет аппаратное ускорение).

Практически все современные процессоры поддерживают SIMD: AVX2 на amd64 и Neon на arm64. Поэтому я решил, что было бы неплохо ускорить RMD160, реализовав его в виде параллельных вычислений. Тем более, я раньше никогда не писал SIMD-код, и мне было интересно это попробовать.

Мой основной компьютер — MacBook на Apple Silicon (M-чипах). Изначально я хотел реализовать RMD160 SIMD на SVE (256 bit / 8 lane), но оказалось, что чипы Apple не поддерживают SVE 🤦 (следует пояснить, что M2-чип реализует стандарт ARMv8.6, а SVE был добавлен в ARMv8.2 с пометкой optional), поэтому пришлось использовать Neon (128 bit / 4 lane). Если это не так, я где-то ошибся, и есть способ запускать SVE-инструкции на M-чипах — буду рад комментариям.

Что такое RMD160?

RIPEMD-160 (RMD160) — это криптографическая хеш-функция, создающая 160-битный хеш из произвольных данных. Она была разработана как безопасная альтернатива более ранним алгоритмам, таким как MD5 и SHA-1. RMD160 широко применяется в блокчейн-технологиях, особенно в Bitcoin, где используется для создания адресов кошельков: публичный ключ сначала хешируется с помощью SHA-256, а затем — RMD160, для повышения безопасности и сокращения длины.

Алгоритм RMD160 состоит из 5 раундов, каждый из которых включает в себя базовые логические функции, циклические сдвиги (ROTL) и сложение. Особенностью RMD160 является то, что каждый раунд выполняется в двух параллельных ветках: основной (левая) и параллельной (правая). Эти две ветки используют разные константы, порядок обработки слов и логические функции, после чего их результаты объединяются.

Есть классическая C-реализация RMD160 с использованием кучи макросов для объявления раундов, логических функций и т.п., но такой код сложно читать, поэтому мне больше нравится реализация в Golang, которую я ранее уже портировал в ecloop. Дальнейшее портирование на Neon я планирую делать на этой основе.

Если отойти немного в сторону — SIMD-инструкции не выглядят чем-то экстремально сложным, но у них нет синтаксического сахара, поэтому вместо a + b нужно писать что-то в духе vaddq_u32(a, b). Такие специальные функции есть для каждой стандартной операции × количество числовых типов (u/i 8/16/32/64, f16/32/64).

RMD160 (как и другие хеш-функции) должно быть не слишком сложно портировать на SIMD, потому что в их алгоритмах нет ветвлений. По сути, алгоритм остаётся таким же — только все операции нужно заменить на SIMD-специфические инструкции.

Простая Neon программа

Чтобы понять, как писать с использованием Neon, следует начать с максимально простой программы — например, умножить 42 × 2. Так как SIMD — это параллельные вычисления, его операции применяются на весь вектор сразу, и результат в отдельных частях вектора должен быть одинаковым. Чтобы убедиться в этом, результат можно вывести в консоль.

#include <arm_neon.h>
#include <stdint.h>
#include <stdio.h>

void print_check(uint32x4_t *a) {
  uint32_t arr[4];
  vst1q_u32(arr, *a); // store 4x32-bit vector into a regular array
  for (int i = 0; i < 4; i++) {
    printf("%x%c", arr[i], i == 3 ? '\n' : ' ');
  }
}

int main() {
  uint32_t a = 42;
  uint32x4_t b = vdupq_n_u32(42); // load u32 to all 4 lanes (42, 42, 42, 42)
  printf("%x = ", a);
  print_check(&b); // out: 2a = 2a 2a 2a 2a

  a = a * 2;
  b = vmulq_n_u32(b, 2); // multiply each lane by 2
  printf("%x = ", a);
  print_check(&b); // out: 54 = 54 54 54 54

  return 0;
}

В общем, идея того, как работают SIMD-вычисления, думаю, понятна. Далее print_check будет использоваться часто для проверки корректности алгоритма.

Базовые функции и ROTL

В вычислении RMD160 используются 5 базовых функций и ROTL — всё остальное это перемешивание данных в определённом порядке. GPT переписал эти макросы, а я проверил их корректность:

// original functions
#define OLD_F1(x, y, z) ((x) ^ (y) ^ (z))
#define OLD_F2(x, y, z) (((x) & (y)) | (~(x) & (z)))
#define OLD_F3(x, y, z) (((x) | ~(y)) ^ (z))
#define OLD_F4(x, y, z) (((x) & (z)) | ((y) & ~(z)))
#define OLD_F5(x, y, z) ((x) ^ ((y) | ~(z)))
#define OLD_ROTL(x, n) (((x) << (n)) | ((x) >> (32 - (n))))

// simd functions
#define F1(x, y, z) veorq_u32(veorq_u32(x, y), z)
#define F2(x, y, z) vorrq_u32(vandq_u32(x, y), vandq_u32(vmvnq_u32(x), z))
#define F3(x, y, z) veorq_u32(vorrq_u32(x, vmvnq_u32(y)), z)
#define F4(x, y, z) vorrq_u32(vandq_u32(x, z), vandq_u32(y, vmvnq_u32(z)))
#define F5(x, y, z) veorq_u32(x, vorrq_u32(y, vmvnq_u32(z)))
#define ROTL(x, n) vorrq_u32(vshlq_n_u32(x, n), vshrq_n_u32(x, 32 - (n)))

void print_check(char *l, uint32_t c, uint32x4_t a) {
  printf("%s: %08x = ", l, c);
  uint32_t arr[4];
  vst1q_u32(arr, a); // store 4x32-bit vector into a regular array
  for (int i = 0; i < 4; i++) {
    printf("%08x%c", arr[i], i == 3 ? '\n' : ' ');
    // assert(arr[i] == c);
  }
}

uint32_t a1, b1, c1;
uint32x4_t a2, b2, c2;

a1 = 0x67452301, b1 = 0xefcdab89, c1 = 0x98badcfe;
a2 = vdupq_n_u32(a1), b2 = vdupq_n_u32(b1), c2 = vdupq_n_u32(c1); // loading vectors

// // compare original and simd functions
print_check("F1", OLD_F1(a1, b1, c1), F1(a2, b2, c2));
print_check("F2", OLD_F2(a1, b1, c1), F2(a2, b2, c2));
print_check("F3", OLD_F3(a1, b1, c1), F3(a2, b2, c2));
print_check("F4", OLD_F4(a1, b1, c1), F4(a2, b2, c2));
print_check("F5", OLD_F5(a1, b1, c1), F5(a2, b2, c2));
print_check("RL", OLD_ROTL(a1, 12), ROTL(a2, 12));

// output:
// F1: 10325476 = 10325476 10325476 10325476 10325476
// F2: ffffffff = ffffffff ffffffff ffffffff ffffffff
// F3: efcdab89 = efcdab89 efcdab89 efcdab89 efcdab89
// F4: 67452301 = 67452301 67452301 67452301 67452301
// F5: 88888888 = 88888888 88888888 88888888 88888888
// RL: 52301674 = 52301674 52301674 52301674 52301674

Проблема с портированием Golang-реализации

Golang-реализации состоит из 5 больших циклов, которые выполняют по 16 левых и правых раундов; внутри каждой операции миксуются входные данные по индексу _n[i] и происходит ROTL по индексу _r[i]. В reference C-implementation используется куча подряд идущих макросов, из-за чего, на мой взгляд, читать такое сложнее.

// Golang implementation
static const u8 _n[80] = { /* ... */ }; // Left DATA indexes
static const u8 _r[80] = { /* ... */ }; // Left ROTL indexes

// round 1
for (; i < 16; ++i) {
  // left branch
  alpha = a1 + F1(b1, c1, d1) + x[_n[i]];
  alpha = rotl32(alpha, _r[i]) + e1;
  beta = rotl32(c1, 10);
  a1 = e1, c1 = b1, e1 = d1, b1 = alpha, d1 = beta;
  // right branch
  // ...
}

// Reference C-implementation
#define F(x, y, z)        ((x) ^ (y) ^ (z))

#define FF(a, b, c, d, e, x, s)        {\
      (a) += F((b), (c), (d)) + (x);\
      (a) = ROL((a), (s)) + (e);\
      (c) = ROL((c), 10);\
   }

// round 1 - left branch
FF(aa, bb, cc, dd, ee, X[ 0], 11);
FF(ee, aa, bb, cc, dd, X[ 1], 14);
// ...
FF(bb, cc, dd, ee, aa, X[14],  9);
FF(aa, bb, cc, dd, ee, X[15],  8);

В общем, если переписать код напрямую с использованием Neon-инструкций, то компиляция падает с ошибкой: vshlq_n_u32 и vshrq_n_u32 требуют, чтобы значение поворота (второй аргумент) было известно на момент компиляции. Пример для сравнения:

// Golang implementation (original)
#define F1(x, y, z) ((x) ^ (y) ^ (z))
#define rotl32(x, n) (((x) << (n)) | ((x) >> (32 - (n))))
alpha = a1 + F1(b1, c1, d1) + x[_n[i]];
alpha = rotl32(alpha, _r[i]) + e1;

// Golang implementation (SIMD)
#define F1(x, y, z) veorq_u32(veorq_u32(x, y), z)
#define ROTL(x, n) vorrq_u32(vshlq_n_u32(x, n), vshrq_n_u32(x, 32 - (n)))
alpha = vaddq_u32(a1, F1(b1, c1, d1));
alpha = vaddq_u32(alpha, X[_n[i]]);
alpha = vaddq_u32(ROTL(alpha, _r[i]), e1);
// err: argument to '__builtin_neon_vshlq_n_v' must be a constant integer
// err: argument to '__builtin_neon_vshrq_n_v' must be a constant integer

Так что придётся использовать версию на макросах, так как там индексы передаются напрямую (последний аргумент в макросе FF) и раскрываются в константные значения во время компиляции. Возможно, это изменение и к лучшему (позже увидим почему).

Обобщённый макрос раунда

Если посмотреть на раунды RMD160, то там происходят одни и те же действия, но меняются: базовая функция, константа, индекс данных и поворот. В общем, макрос раунда был выше (я взял немного другой код с GitHub). Моя цель — портировать макрос раунда на SIMD.

В раунде мы складываем 4 переменные, делаем ROTL + ещё одно сложение и отдельный ROTL для другой переменной. Так как операции сложения "+" нет в SIMD, нужно использовать специальные инструкции.

Я добавил несколько макросов для сложения векторов и описал сам раунд:

#define ADD2(a, b) vaddq_u32(a, b)
#define ADD3(a, b, c) vaddq_u32(vaddq_u32(a, b), c)
#define ADD4(a, b, c, d) vaddq_u32(vaddq_u32(vaddq_u32(a, b), c), d)

#define RN(a, b, c, d, e, f, x, k, r) \
  u = ADD4(a, f, x, vdupq_n_u32(k));  \
  a = ADD2(ROTL(u, r), e);            \
  c = ROTL(c, 10);

В макросе a, b, c, d, e — это переменные состояния, f — значение после вычисления базовой функции, x — это uint32 данных по индексу для текущей итерации, k — константа и r — значение поворота для ROTL.

vdupq_n_u32(k) загружает константу в вектор (одинаковое значение во все 4 lanes). Ранее мы писали код, чтобы умножить вектор на число; для этого используется vmulq_n_u32. Логично предположить, что инструкция для добавления числа к вектору должна быть vaddq_n_u32, но её нет. Вместо этого нужно писать в стиле vaddq_u32(vec1, vdupq_n_u32(2)) (если кто знает, почему так — пишите в комментарии).

Далее, на основании этого макроса, можно определить левые и правые раунды. Тут код аналогичен любой другой реализации на макросах (разве что названия раундов я сделал как Li/Ri).

#define L1(a, b, c, d, e, x, r) RN(a, b, c, d, e, F1(b, c, d), x, 0, r)
#define L2(a, b, c, d, e, x, r) RN(a, b, c, d, e, F2(b, c, d), x, 0x5A827999ul, r)
#define L3(a, b, c, d, e, x, r) RN(a, b, c, d, e, F3(b, c, d), x, 0x6ED9EBA1ul, r)
#define L4(a, b, c, d, e, x, r) RN(a, b, c, d, e, F4(b, c, d), x, 0x8F1BBCDCul, r)
#define L5(a, b, c, d, e, x, r) RN(a, b, c, d, e, F5(b, c, d), x, 0xA953FD4Eul, r)
#define R1(a, b, c, d, e, x, r) RN(a, b, c, d, e, F5(b, c, d), x, 0x50A28BE6ul, r)
#define R2(a, b, c, d, e, x, r) RN(a, b, c, d, e, F4(b, c, d), x, 0x5C4DD124ul, r)
#define R3(a, b, c, d, e, x, r) RN(a, b, c, d, e, F3(b, c, d), x, 0x6D703EF3ul, r)
#define R4(a, b, c, d, e, x, r) RN(a, b, c, d, e, F2(b, c, d), x, 0x7A6D76E9ul, r)
#define R5(a, b, c, d, e, x, r) RN(a, b, c, d, e, F1(b, c, d), x, 0, r)

Теперь, используя эти макросы, можно написать первую итерацию первого раунда, сравнить её с работающей реализацией. Если всё ок, тогда можно скопировать весь раунд целиком, проверить его, а затем и все оставшиеся раунды. Результат я сравнивал функцией print_check, которую делал ранее.

Первый левый раунд, первая итерация:

#define K1 0x67452301
#define K2 0xEFCDAB89
#define K3 0x98BADCFE
#define K4 0x10325476
#define K5 0xC3D2E1F0

void rmd160_block(uint32x4_t *s, const uint32_t x[4][16]) {
  // a1-e1 left rounds state, a2-e2 right rounds state, u - temp varible used in RD macro
  uint32x4_t a1, b1, c1, d1, e1, a2, b2, c2, d2, e2, u;
  // Load initial constants
  a1 = a2 = vdupq_n_u32(K1);
  b1 = b2 = vdupq_n_u32(K2);
  c1 = c2 = vdupq_n_u32(K3);
  d1 = d2 = vdupq_n_u32(K4);
  e1 = e2 = vdupq_n_u32(K5);

  uint32x4_t w[16]; // Load data to vector
  for (int i = 0; i < 16; i++) {
    // Load 4x32-bit integers from x[0][i], x[1][i], x[2][i], x[3][i]
    // w[i] = vsetq_lane_u32(x[0][i], w[i], 0);
    // w[i] = vsetq_lane_u32(x[1][i], w[i], 1);
    // w[i] = vsetq_lane_u32(x[2][i], w[i], 2);
    // w[i] = vsetq_lane_u32(x[3][i], w[i], 3);
    w[i] = vld1q_u32(((uint32_t[4]){x[0][i], x[1][i], x[2][i], x[3][i]})); // A bit faster
  }

  L1(a1, b1, c1, d1, e1, w[0], 11);
  print_check("a1", 0, a1);
  print_check("b1", 0, b1);
  print_check("c1", 0, c1);
  print_check("d1", 0, d1);
  print_check("e1", 0, e1);
}

uint32x4_t s[5] = {0}; // initial state
s[0] = vdupq_n_u32(K1);
s[1] = vdupq_n_u32(K2);
s[2] = vdupq_n_u32(K3);
s[3] = vdupq_n_u32(K4);
s[4] = vdupq_n_u32(K5);

uint32_t x[4][16] = {0}; // data block, filled with zeros
rmd160_block((uint32x4_t *)s, x);

Следует заметить, что обычно хеш-функции тестируют на нулевых данных (для простоты работы). Данные в хеш-функциях обрабатываются по блокам. Блок в RMD160 — это 32×16 = 512 бит. rmd160_block можно вызывать несколько раз с тем же состоянием (он меняется) и новыми данными — для случаев, когда нужно посчитать хеш сообщения, большего чем один раунд. В моей задаче (генерация адресов) все сообщения помещаются в один блок. Результат первого раунда vs текущая реализация:

// a1: 1602f864 1602f864 1602f864 1602f864 vs c3d2e1f0
// a1: efcdab89 efcdab89 efcdab89 efcdab89 vs 1602f864
// a1: eb73fa62 eb73fa62 eb73fa62 eb73fa62 vs efcdab89
// a1: 10325476 10325476 10325476 10325476 vs eb73fa62
// a1: c3d2e1f0 c3d2e1f0 c3d2e1f0 c3d2e1f0 vs 10325476

В общем, эти значения ± похожи на значения из текущей версии, отличаются на одно смещение. Это не проблема, так как переменных 5, и к концу смещения они выравняются. Просто разница в реализациях.

Все раунды я писать не буду, их там по 80 с каждой стороны (всего 160) — выйдет слишком длинно. Левые и правые раунды не зависят друг от друга, и вычислять их можно в любом порядке: либо сначала все левые / все правые, либо чередовать левые / правые, либо вообще чередовать итерации внутри раунда. На финальный результат это не повлияет.

Финализация RMD160

В конце блока RMD160 нужно объединить старое состояние с локальным состоянием — это тоже три сложения со смещением индексов.

void rmd160_block(uint32x4_t *s, const uint32_t x[4][16]) {
  // ... 160 rounds

  uint32x4_t t = s[0];
  s[0] = ADD3(s[1], c1, d2);
  s[1] = ADD3(s[2], d1, e2);
  s[2] = ADD3(s[3], e1, a2);
  s[3] = ADD3(s[4], a1, b2);
  s[4] = ADD3(t, b1, c2);
}

Финально остаётся изменить endianness у значений (RMD160 использует не тот endianness) и выгрузить значения из вектора в результирующий массив.

// ... init & rmd160_block

for (int i = 0; i < 5; ++i) {
  // swap32 for uint32x4_t (can it be shorter?)
  s[i] = vreinterpretq_u32_u8(vrev32q_u8(vreinterpretq_u8_u32(s[i])));
}

uint32_t r[4][5] = {0}; // result stored as 4x5 uint32_t
for (int i = 0; i < 5; i++) { // load it from uint32x4_t
  r[0][i] = vgetq_lane_u32(s[i], 0);
  r[1][i] = vgetq_lane_u32(s[i], 1);
  r[2][i] = vgetq_lane_u32(s[i], 2);
  r[3][i] = vgetq_lane_u32(s[i], 3);
}

На этом, в общем, и всё — r может использоваться дальше, где нужно (r[0], r[1], r[2], r[3] — это посчитанные хеши, 4 сразу).

Подводя итог по этой секции, полный алгоритм параллельного RMD160 выглядит так:

Инициализировать стейт длиной 160 бит × 4 lanes (uint32x4_t s[5]).
Разбить сообщение (данные) на блоки по 512 бит × 4 lanes (uint32_t x[4][16]).
Прокрутить RMD160 раунды, пока данные не закончатся (rmd160_block сам считывает данные в вектор).
Изменить endianness в финальном стейте.
Выгрузить вектор финального стейта в массив хешей (int32_t r[4][5]).

Производительность RMD160 SIMD

Теперь остаётся замерить то, зачем это затевалось — сравнить производительность оригинального и SIMD-кода. Для этого я сделал небольшой benchmark:

size_t tsnow() {
  struct timespec ts;
  clock_gettime(CLOCK_REALTIME, &ts);
  return ts.tv_sec * 1000 + ts.tv_nsec / 1e6;
}

void rmd160_simd() {
  uint32_t r[4][5] = {0};
  uint32_t x[4][16] = {0};

  size_t stime = tsnow();
  size_t iters = 1000 * 1000 * 32;
  for (size_t i = 0; i < iters; ++i) rmd160_4w(r, x);
  double dt = (tsnow() - stime) / 1000.0;
  double ir = iters / dt / 1000000;
  double hr = ir * 4; // 4 hash per iter
  printf("%.2fM it/s ~ %.2fM h/s ~ %.2fs\n", ir, hr, dt);

  printf("s[0]: %08x\n", r[0][0]);
  printf("s[1]: %08x\n", r[0][1]);
  printf("s[2]: %08x\n", r[0][2]);
  printf("s[3]: %08x\n", r[0][3]);
  printf("s[4]: %08x\n", r[0][4]);
}

void rmd160_naive() {
  uint32_t s[5] = {0};
  uint32_t x[16] = {0};

  size_t stime = tsnow();
  size_t iters = 1000 * 1000 * 32;
  for (size_t i = 0; i < iters; ++i) rmd160_1w(s, x);
  double dt = (tsnow() - stime) / 1000.0;
  double ir = iters / dt / 1000000;
  double hr = ir * 1; // 1 hash per iter
  printf("%.2fM it/s ~ %.2fM h/s ~ %.2fs\n", ir, hr, dt);

  printf("s[0]: %08x\n", s[0]);
  printf("s[1]: %08x\n", s[1]);
  printf("s[2]: %08x\n", s[2]);
  printf("s[3]: %08x\n", s[3]);
  printf("s[4]: %08x\n", s[4]);
}

Скомпилировал обе программы с -O3 и запустил (на базовом Apple M2):

❯ clang -O3 -march=native ./lib/rmd160.c && ./a.out # original
5.50M it/s ~ 5.50M h/s ~ 5.81s

❯ clang -O3 -march=native ./lib/rmd160s.c && ./a.out # neon
2.14M it/s ~ 8.55M h/s ~ 14.98s

Вышло, что версия на Neon (128 бит / 4 lanes) работает на 55% быстрее. Что, конечно, крутой результат, но печально, что на M-chips нет SVE для 256/512 бит (8/16 lanes) — так было бы ещё лучше!

One more thing

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

Я поменял порядок раундов на чередование левых и правых (L1 / R1, L2 / R2), и скорость работы значительно возросла. Я изначально подумал, что ошибка в данных, но print_check (в качестве тестов) говорит, что всё в порядке.

Я решил попробовать чередовать итерации (L1_1 R1_1 L1_2 R1_2 и т.д.). Честно говоря, переставлять 160 строчек — не самое веселое занятие, но результат удивил меня ещё больше.

Сравнение разных размещений (три теста самой RMD160 функции и полный цикл работы логики ecloop):

# L1_1 L2_2 .. L5_16 R1_1 R2_2 .. R5_16 (+56%)
2.25M it/s ~ 9.02M h/s ~ 14.19s
2.23M it/s ~ 8.93M h/s ~ 14.33s
2.23M it/s ~ 8.94M h/s ~ 14.32s
ecloop (addr33 x 8 core) ~ 19.53M it/s (+22%)

# L1_1-L1_16 R1_1-R1_16 L2_1-L2_16 .. (+165%)
3.70M it/s ~ 14.80M h/s ~ 8.65s
3.85M it/s ~ 15.42M h/s ~ 8.30s
3.87M it/s ~ 15.46M h/s ~ 8.28s
ecloop (addr33 x 8 core) ~ 22.46M it/s (+40%)

# L1_1 R1_1 L1_2 R1_2 .. L5_16 R5_16 (+175%)
3.96M it/s ~ 15.82M h/s ~ 8.09s
3.94M it/s ~ 15.78M h/s ~ 8.11s
3.94M it/s ~ 15.76M h/s ~ 8.12s
ecloop (addr33 x 8 core) ~ 24.83M it/s (+55%)

Для меня загадка, почему это так работает, и, возможно, есть ещё более эффективная расстановка? Кто знает — пишите в комментарии.

Поддержка AVX2 (AMD64)

Изначально у меня не было этого в планах, но алгоритм RMD160 на макросах вышел довольно абстрактным, и дальнейшее портирование на AVX2 выглядело довольно простым. Основное отличие AVX2 от Neon (кроме другого набора инструкций) — это размер вектора: 256 бит против 128 бит. То есть, можно посчитать 8 хешей параллельно (против 4-х у Neon).

Дальнейшее портирование состоит из таких этапов:

вынести весь Neon-специфический код в макросы
переписать все макросы под AVX2
проверить корректность работы на amd64

Сейчас напрямую в коде алгоритма используются такие Neon-инструкции: тип вектора (uint32x4_t), инициализация состояния через vdupq_n_u32, endian-swap и load / dump данных в вектор.

Переношу эти вещи в макросы (на всякий случай я добавил префикс RMD_, чтобы не было конфликтов с другими файлами):

#define RMD_LEN 4                    // vector length
#define RMD_VEC uint32x4_t           // vector type
#define RMD_LD_NUM(x) vdupq_n_u32(x) // load same number into all lanes

#define RMD_SWAP(x) vreinterpretq_u32_u8(vrev32q_u8(vreinterpretq_u8_u32(x)))
#define RMD_LOAD(x, i) vld1q_u32(((uint32_t[4]){x[0][i], x[1][i], x[2][i], x[3][i]}))
#define RMD_DUMP(r, s, i)                                                                        \
  do {                                                                                           \
    r[0][i] = vgetq_lane_u32(s[i], 0);                                                           \
    r[1][i] = vgetq_lane_u32(s[i], 1);                                                           \
    r[2][i] = vgetq_lane_u32(s[i], 2);                                                           \
    r[3][i] = vgetq_lane_u32(s[i], 3);                                                           \
  } while (0);

И обновить текущий код на что-то такого рода:

void rmd160_block(RMD_VEC *s, const uint32_t x[RMD_LEN][16]) {
  RMD_VEC a1, b1, c1, d1, e1, a2, b2, c2, d2, e2, u;
  a1 = a2 = RMD_LD_NUM(RMD_K1);
  b1 = b2 = RMD_LD_NUM(RMD_K2);
  c1 = c2 = RMD_LD_NUM(RMD_K3);
  d1 = d2 = RMD_LD_NUM(RMD_K4);
  e1 = e2 = RMD_LD_NUM(RMD_K5);

  RMD_VEC w[16];
  for (int i = 0; i < 16; i++) w[i] = RMD_LOAD(x, i);
  // ... rounds and iterations
}

// new function to process full single block
void rmd160_batch(uint32_t r[RMD_LEN][5], const uint32_t x[RMD_LEN][16]) {
  RMD_VEC s[5] = {0}; // load initial state
  s[0] = RMD_LD_NUM(RMD_K1);
  s[1] = RMD_LD_NUM(RMD_K2);
  s[2] = RMD_LD_NUM(RMD_K3);
  s[3] = RMD_LD_NUM(RMD_K4);
  s[4] = RMD_LD_NUM(RMD_K5);

  rmd160_block((RMD_VEC *)s, x);                     // round
  for (int i = 0; i < 5; ++i) s[i] = RMD_SWAP(s[i]); // change endian
  for (int i = 0; i < 5; ++i) RMD_DUMP(r, s, i);     // dump data to array
}

Вышло, конечно, уже достаточно магически, но самих изменений реально не так много. Теперь следует добавить переопределённые макросы для AVX2. Также я дополнительно обернул серии макросов, специфичных для конкретной архитектуры, в #ifdef. Таким образом, по сути, у меня есть один код алгоритма RMD160, и нужные макросы подключаются в зависимости от того, на какой архитектуре компилируется программа.

#if defined(__aarch64__) && defined(__ARM_NEON)
  #include <arm_neon.h>

  #define RMD_LEN 4                    // vector length
  #define RMD_VEC uint32x4_t           // vector type
  // ... move all current Neon related macros here
#elif defined(__x86_64__) && defined(__AVX2__)
  #include <immintrin.h>

  #define RMD_LEN 8
  #define RMD_VEC __m256i
  #define RMD_LD_NUM(x) _mm256_set1_epi32(x)

  #define RMD_SWAP(x)                                                                              \
    _mm256_shuffle_epi8((x), _mm256_setr_epi8(3, 2, 1, 0, 7, 6, 5, 4, 11, 10, 9, 8, 15, 14, 13,    \
                                              12, 19, 18, 17, 16, 23, 22, 21, 20, 27, 26, 25, 24,  \
                                              31, 30, 29, 28))

  #define RMD_LOAD(x, i)                                                                           \
    _mm256_set_epi32(x[0][i], x[1][i], x[2][i], x[3][i], x[4][i], x[5][i], x[6][i], x[7][i])

  #define RMD_DUMP(r, s, i)                                                                        \
    do {                                                                                           \
      r[0][i] = _mm256_extract_epi32(s[i], 0);                                                     \
      r[1][i] = _mm256_extract_epi32(s[i], 1);                                                     \
      r[2][i] = _mm256_extract_epi32(s[i], 2);                                                     \
      r[3][i] = _mm256_extract_epi32(s[i], 3);                                                     \
      r[4][i] = _mm256_extract_epi32(s[i], 4);                                                     \
      r[5][i] = _mm256_extract_epi32(s[i], 5);                                                     \
      r[6][i] = _mm256_extract_epi32(s[i], 6);                                                     \
      r[7][i] = _mm256_extract_epi32(s[i], 7);                                                     \
    } while (0);

  #define _mm256_not_si256(x) _mm256_xor_si256((x), _mm256_set1_epi32(0xffffffff))
  #define RMD_F1(x, y, z) _mm256_xor_si256(x, _mm256_xor_si256(y, z))
  #define RMD_F2(x, y, z) _mm256_or_si256(_mm256_and_si256(x, y), _mm256_andnot_si256(x, z))
  #define RMD_F3(x, y, z) _mm256_xor_si256(_mm256_or_si256(x, _mm256_not_si256(y)), z)
  #define RMD_F4(x, y, z) _mm256_or_si256(_mm256_and_si256(x, z), _mm256_andnot_si256(z, y))
  #define RMD_F5(x, y, z) _mm256_xor_si256(x, _mm256_or_si256(y, _mm256_not_si256(z)))

  #define RMD_ROTL(x, n) _mm256_or_si256(_mm256_slli_epi32(x, n), _mm256_srli_epi32(x, 32 - (n)))
  #define RMD_ADD2(a, b) _mm256_add_epi32(a, b)
  #define RMD_ADD3(a, b, c) _mm256_add_epi32(_mm256_add_epi32(a, b), c)
  #define RMD_ADD4(a, b, c, d) _mm256_add_epi32(_mm256_add_epi32(a, b), _mm256_add_epi32(c, d))
#else
  #error "Unsupported arch for RIPEMD-160 (AVX2 or NEON required)"
#endif

Основные отличия следующие:

другой заголовочный файл
другой тип вектора (8 lanes вместо 4 у Neon) и названия intrinsics
у AVX2 нет Bitwise NOT, поэтому пришлось добавить его отдельно как _mm256_not_si256.
нет отдельной функции для endian-swap, но есть более обобщённая функция, чтобы переставлять биты в заданном порядке — _mm256_shuffle_epi8 (первый аргумент — где переставить биты, второй аргумент — как переставить).
_mm256_set_epi32 позволяет удобнее загружать данные в разные lanes, в Neon пришлось использовать временный массив (вариант с установкой каждой lane по отдельности (vsetq_lane_u32) оказался более медленным).

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

Производительность AVX2 версии

У меня есть небольшой Fanless PC с Linux на Intel N100, который я использую для нативного тестирования приложений. На нем я запустил бенчмарк, написанный ранее, и получил такие результаты:

❯ clang -O3 -march=native ./lib/rmd160.c && ./a.out # original (on Intel N100)
4.26M it/s ~ 4.26M h/s ~ 7.51s

❯ clang -O3 -march=native ./lib/rmd160s.c && ./a.out # avx2 (on Intel N100)
2.25M it/s ~ 17.96M h/s ~ 14.25s

8 lanes AVX2 и правильная расстановка раундов в алгоритме (итерации "зеброй") дают прирост 320% в количестве хешей в секунду по сравнению с оригинальным кодом. Что интересно, AVX2 на Intel N100 работает на 20% быстрее, чем Neon на Apple M2 (в основном из-за размера вектора). Ускорение работы программы в целом составило: 5.45M it/s vs 7.73M it/s (+42%).

Fallback реализация для старых процессоров / VMs

В #ifdef выше я оставил секцию #else с #error, чтобы компиляция не происходила на неподдерживаемых системах. В общем, это не совсем хорошее решение, и хотелось бы, чтобы программа работала везде (в основном это касается потенциального запуска в виртуальных машинах). Так как весь алгоритм уже написан на макросах, добавление новой реализации не составит труда. Просто переопределяю все макросы на размер вектора 1 и uint32_t в качестве "векторного" типа. В реальности программа будет работать с единичным массивом, что с точки зрения памяти в C примерно то же самое, что и просто использование uint32_t.

#else
  #warning "Fallback RIPEMD-160 implementation used. AVX2 or NEON required for SIMD"

  #define RMD_LEN 1
  #define RMD_VEC uint32_t
  #define RMD_LD_NUM(x) x

  #define RMD_SWAP(x) __builtin_bswap32(x)
  #define RMD_LOAD(x, i) x[0][i]
  #define RMD_DUMP(r, s, i) r[0][i] = s[i]

  #define RMD_F1(x, y, z) ((x) ^ (y) ^ (z))
  #define RMD_F2(x, y, z) (((x) & (y)) | (~(x) & (z)))
  #define RMD_F3(x, y, z) (((x) | ~(y)) ^ (z))
  #define RMD_F4(x, y, z) (((x) & (z)) | ((y) & ~(z)))
  #define RMD_F5(x, y, z) ((x) ^ ((y) | ~(z)))

  #define RMD_ROTL(x, n) (((x) << (n)) | ((x) >> (32 - (n))))
  #define RMD_ADD2(a, b) (a + b)
  #define RMD_ADD3(a, b, c) (a + b + c)
  #define RMD_ADD4(a, b, c, d) (a + b + c + d)
#endif

Запустил, проверил — работает корректно, разве что скорость немного возросла из-за нового порядка раундов. Точно таким же образом несложно добавить реализацию для AVX512 (16 lanes), но у меня нет подходящего процессора для проверки, поэтому я этого не сделал. Да и без этого статья уже получилась достаточно длинной.

Выводы

SIMD-программирование оказалось проще, чем я ожидал. Нужные intrinsics можно легко найти с помощью GPT, что значительно упрощает задачу. Самостоятельно их искать сложно, потому что существует множество возможных комбинаций инструкций. Алгоритм RMD160 в основном используется в криптовалюте (по крайней мере, я не знаю других популярных сценариев использования), поэтому практическая ценность полученного кода вне обучающего контекста может быть сомнительной.

SIMD-вычисления дают отличный прирост скорости выполнения, но, конечно, важно учитывать специфику задачи: они работают эффективно, когда нужно обработать большое количество данных одинакового размера. Нет смысла использовать SIMD, если один блок данных для хеширования имеет размер 1, а другой — 100 (например, при обработке различных файлов). Основная программа, в свою очередь, должна быть способна обрабатывать данные батчами.

Финальный код одним файлом на Github.