12-строчный SIMD-патч мейнтейнера терминала дал пятикратное ускорение — и он записал паттерн, который работает всегда

Проблема репутации SIMD и решение из пяти шагов

Эссе Митчелла Хашимото открывается прямым вызовом тому, как большинство разработчиков думают о SIMD (Single Instruction, Multiple Data), функции CPU, обрабатывающей несколько значений за одну инструкцию вместо одного за раз, где реальное ускорение напрямую масштабируется с тем, сколько значений помещается в векторный регистр. Его аргумент: у SIMD незаслуженная репутация экзотической, почти научной техники оптимизации, тогда как на практике подавляющее большинство реального векторизованного кода следует одному повторяющемуся паттерну: разослать константу в векторную форму, пройти циклом по чанкам ширины вектора вместо отдельных элементов, применить операцию параллельно ко всем полосам сразу, свернуть результаты обратно по необходимости и обработать то, что осталось: «остаток», не делящийся ровно на ширину вектора, обычным скалярным циклом в конце.

Доказательство на реальном продакшн-коде, не на игрушечном примере

Вместо синтетического бенчмарка Хашимото проходит через настоящий код Ghostty, терминального эмулятора, который он поддерживает: рутину, находящую последовательности печатаемых символов в выводе терминала. Скалярная версия — одна строка. Векторизованная версия, следуя его пятишаговому паттерну в точности, вырастает до двенадцати строк, а реальная отдача масштабируется вместе с доступным набором инструкций: до 4x на ARM NEON, до 8x на AVX2 (базовый вариант для большинства современных чипов x86), до 16x на AVX-512. В реальном сквозном тестировании на системе с AVX2 изменение дало примерно пятикратное реальное ускорение, не синтетическую цифру микробенчмарка, а измеренное улучшение в настоящей рабочей нагрузке настоящего терминала.

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

Почему рукописный код побеждает «компилятор сам разберётся»

Один ответ в треде на 111 комментариев мягко возразил против самой идеи писать вручную: современные компиляторы автовекторизуют массу простых циклов одним флагом вроде gcc -O3, без ручного SIMD. Контраргумент, процитированный из самого эссе и развитый другим комментатором, про контроль, а не про голую скорость: «когда этот цикл достаточно важен, чтобы меня заботило пятикратное ускорение, я хочу, чтобы векторизация была явной и предсказуемой. Я не хочу, чтобы несвязанное изменение кода или обновление компилятора тихо превратило её обратно в скалярный цикл». Автовекторизация реально хрупка: обновление компилятора, изменение в несвязанной функции или даже замена константы 1 на 1.0 где-то ещё в файле способны молча отключить оптимизацию, на которую кодовая база тихо полагалась, без единой ошибки и предупреждения, просто регрессия производительности, которую никто не заметит, пока её не измерят. Один комментатор привёл тот же паттерн сбоя из совершенно другой области — JIT-компилятора V8, — где идентичный класс бага «невидимая оптимизация, которая тихо исчезает» постоянно всплывает в работе над производительностью JavaScript. Рукописный SIMD меняет немного объёма кода и читаемости на гарантию: быстрый путь существует, потому что вы его туда положили, и остаётся там, пока вы его не уберёте, а не пока какое-то несвязанное обновление зависимости тихо его не заберёт.