Как эмулировать inline-ассемблер в Haskell, которого там нет

Задача простая на словах: перемножить два Word64 и получить обе половины 128-битного результата через одну машинную инструкцию mulq. В GHC нет inline assembly, и разработчик под ником minoki перебрал все возможные обходные пути, от честного FFI до чёрной магии на уровне calling convention.

🔘 unsafe FFI с указателем через alloca работает, но тянет за собой IO и лишнюю память;
🔘 unsafe FFI в два вызова, отдельно для старшей и младшей половины, укладывает всё в регистры без указателей;
🔘 unsafe FFI через XMM-регистры возвращает обе половины сразу, но требует __m128i на стороне C;
🔘 foreign import prim позволяет написать собственный PrimOp прямо на ассемблере, с ручным учётом регистров STG (%rbx, %r14, jmp *(%rbp)) и макросов LEADING_UNDERSCORE и TABLES_NEXT_TO_CODE;
🔘 отдельная ассемблерная обёртка переводит между C calling convention и GHC calling convention, чтобы дёргать C-функцию, которая возвращает unsigned __int128 структурой по значению.

На Zen4 в WSL2 встроенный timesWord2# отработал за 4 нс, foreign import prim на чистом ассемблере уложился в 4,5 нс, а unsafe FFI с указателем скатился до 19 нс. Safe FFI для такого короткого вызова вышел медленнее 60 нс, то есть медленнее чистого Haskell на Integer.

Сохранять тем, кто когда-нибудь спорил, действительно ли safe FFI в GHC настолько накладен, как все говорят.

@prog_stuff

Rust-компилятор, переписанный в 46 миллионов строк C

Rustc — самокомпилирующийся компилятор Rust — переведён в 46 миллионов строк C и собирается обычным GCC и make, без единой строчки cargo или rustc в цепочке сборки. Автор — разработчик бэкенда cilly, который компилирует Rust в C.

🔘это уже 14-я попытка автора скомпилировать Rust в C — до этого были публичные и приватные проекты вроде rustc_codegen_clr;
🔘бэкенд генерирует «witness»-программы, которые прощупывают, что поддерживает целевой C-компилятор и платформа, и подстраивает вывод под них;
🔘получившийся код собирает core, alloc и std и способен пересобрать сам себя;
🔘практической пользы для повседневной разработки в этом немного — это демонстрация переносимости, а не замена rustc.

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

Полная статья: https://github.com/FractalFir/crustc

@prog_stuff

Почему картинка NES дрожит, хотя кадр статичный

Если подключить NES по композитному видео, изображение заметно «плывёт» даже на неподвижной сцене. Автор блога Nicole Express разобрала по таймингам, откуда берётся эта дрожь и почему она была спроектирована намеренно.

🔘 в стандарте NTSC частота цветовой поднесущей делится на частоту строк с остатком ровно 0,5 — RCA подобрала это полуцелое число специально, чтобы телевизору было проще отделять цвет от яркости;
🔘 кварц NES на 21,47727 МГц — это ровно шесть частот поднесущей, а видеочип PPU использует оба фронта сигнала, отсюда 12 фазовых оттенков в палитре приставки;
🔘 но строка у NES длиннее стандартной: 341 точка. На строку приходится не 227,5, а 227,33 цикла цвета, поэтому фазовый узор повторяется каждые три строки, а не две — картинка и рябит иначе, чем у Apple II или PC Engine;
🔘 инженеры Ricoh намеренно «портят» одну строку кадра: она чередуется между 341 и 340 точками, из-за чего из трёх возможных фазовых выравниваний экран видит только два, сменяющихся через кадр. Автор называет это самой ленивой версией интерлейсинга;
🔘 в PAL-версии приставки этого трюка нет вовсе — там другой кварц и другие делители;
🔘 по шуму на скриншотах Battletoads виден трёхкадровый повторяющийся узор: игра каждый кадр отключает рендеринг на несколько строк ради записи в видеопамять, и «пропавшая точка» проявляется прямо в помехах.

Полная статья: https://nicole.express/2026/phase-altering-by-line.html

Сохранять тем, кто любит, когда странности старого железа объясняются до последнего такта.

@prog_stuff

Как переписывать историю Git без цепочки интерактивных rebase

Автор разобрал экспериментальную команду git history из Git 2.54–2.55. Она меняет старый коммит и сама перестраивает всех его потомков.

🔘 fixup встраивает staged-правку в выбранный коммит;
🔘 reword меняет сообщение, не затрагивая рабочее дерево;
🔘 split делит коммит на части по выбранным hunks.

Операции атомарны. При конфликте Git оставляет историю в исходном состоянии. Merge-коммиты пока не поддерживаются, сохранить конфликт для ручного продолжения тоже нельзя. Поэтому область применения уже, чем у интерактивного rebase.

Полная статья: https://lalitm.com/post/git-history/

@prog_stuff

Конкурентность в стиле Go, собранная поверх pthreads

Автор собрал на C знакомые по Go примитивы: мьютексы, condition variables, атомики, ограниченный пул воркеров и buffered/unbuffered channels. Затем сравнил их стоимость с реализацией Go.

🔘 атомики и свободные мьютексы работают на уровне Go или быстрее благодаря тонкой обёртке;
🔘 парковка потока и системные пробуждения замедляют condition variables в 7–10 раз;
🔘 на крупных задачах worker pool укладывается примерно в 10% от результата Go;
🔘 мелкая передача работы лучше даётся дешёвым goroutines.

Преимущество pthreads сохраняется на крупных задачах с редкой синхронизацией. Частые переключения быстро съедают выигрыш и оставляют системные потоки далеко позади runtime scheduler.

Полная статья: https://antonz.org/concurrency-in-c/

@prog_stuff

Нормальные TLS-сертификаты для внутренних сервисов

Автор настроил внутренние сервисы с сертификатами публичного ACME CA. Схема использует собственный домен, split-horizon DNS, VPN и nginx.

🔘 внешний и внутренний DNS возвращают разные адреса одного имени;
🔘 acme.sh получает сертификат и обновляет его по расписанию;
🔘 nginx слушает VPN-интерфейс и закрывает сервис от внешней сети;
🔘 SAN, CNAME и wildcard-сертификаты дают разные варианты организации имён.

Критичное место схемы — bind nginx: ошибка в адресе откроет сервис наружу. При наличии API у DNS-провайдера выпуск сертификата через DNS-01 часто требует меньше настроек, чем описанный HTTP-01.

Полная статья: https://tuxnet.dev/posts/tls-for-internal-services/

@prog_stuff

Задержка в Linux: X11, Wayland, VRR и DXVK в миллисекундах

Марко Нетт собрал прибор для измерения задержки от клика до появления кадра. RP2040 эмулирует мышь с частотой опроса 1000 Гц, а фотодиод считывает яркость экрана примерно каждые 24 микросекунды. Для каждой конфигурации автор провёл три серии по сто кликов.

🔘 медианы восьми основных конфигураций уложились в 4,21–4,93 мс;
🔘 нативный X11 опередил нативный Wayland на 0,14–0,22 мс;
🔘 VRR снял 0,26–0,45 мс и уменьшил разброс результатов;
🔘 самый заметный штраф принёс XWayland: до 3,13 мс;
🔘 dxvk-low-latency дал до 0,84 мс в тесте без ограничения FPS.

Измерения сделаны на одном компьютере с RTX 4070 Super, монитором 500 Гц и KDE Plasma. На другом железе соотношение может измениться. Схемы прибора, прошивка, анализатор и сырые CSV опубликованы вместе со статьёй.

Полная статья: https://marco-nett.de/blog/measuring-input-latency-on-linux-x11-vs-wayland-vrr-dxvk/

@prog_stuff