« Все должны знать SIMD »: напоминание Митчелла Хашимото о единственной оптимизации, которая всё ещё имеет значение

Митчелл Хашимото (основатель HashiCorp) публикует эссе с простой тезис: в эпоху многоядерных процессоров незнание SIMD означает потерю производительности в 4–16 раз.

Конкретный случай

Митчелл Хашимото — сооснователь HashiCorp, ставший плодовитым независимым участником (ныне работает над Ghostty, своим эмулятором терминала на Zig) — публикует длинный пост под простым названием Everyone Should Know SIMD. Тезис сводится к одной фразе: в мире, где частота CPU топчется на месте, а регистры расширяются, игнорировать SIMD — значит оставлять неиспользованными порядки величин производительности.

SIMD (Single Instruction, Multiple Data) обозначает инструкции CPU, которые применяют одну и ту же операцию к нескольким значениям одновременно — складывать восемь float за один такт, сравнивать шестнадцать байт сразу. На современных CPU x86-64 это наборы инструкций SSE / AVX / AVX2 / AVX-512. На ARM (Apple Silicon, серверы Neoverse) это NEON и SVE.

Под капотом: почему тема снова актуальна

Этот вопрос не нов — SIMD существует с MMX (1996). Что изменилось:

1. Ширина регистров: 128 бит (SSE, NEON) → 256 бит (AVX2) → 512 бит (AVX-512). Регистр AVX-512 вмещает 16 float32 или 64 int8.
2. Доступность: AVX2 есть на всех массовых x86-процессорах с Haswell (2013). NEON стандартен на всех ARMv8 (iPhone 5S и новее, все ARM-серверы).
3. Частота CPU достигла потолка: прирост от поколения к поколению становится всё меньше. А векторизация продолжает окупаться.
4. Авто-векторизаторы имеют ограничения: компиляторы (LLVM, GCC) хорошо векторизуют простые циклы, но часто терпят неудачу при наличии ветвлений, chasing указателей или специфических накоплений. Программисту приходится делать это вручную.

Что говорит Хашимото

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

Конкретные примеры:

• simdjson парсит JSON со скоростью 3-5 ГБ/с на современном CPU, во многом благодаря SIMD.
• Сортировочные движки VqSort (Google) и ips4o используют SIMD, чтобы обойти std::sort в 3-5 раз на массивах целых чисел.
• Колонные СУБД (ClickHouse, DuckDB) построены вокруг SIMD-ядер.
• Парсинг Protobuf и UTF-8 можно векторизовать для аналогичного прироста.

Другими словами: это больше не нишевая тема, а базовый навык для всего, что связано с производительностью на больших объёмах данных.

Как начать без риска утонуть

Ручная работа с SIMD считается сложной: нечитаемые интринсики, хрупкая переносимость между x86 и ARM. Сегодня есть три жизнеспособных подхода:

1. Highway (Google): C++-библиотека, которая абстрагирует SSE/AVX/NEON/SVE за единым API, выбирая реализацию в рантайме в зависимости от CPU.
2. std::simd (предложено для C++26): входит в STL, переносимо, но пока экспериментально.
3. Переносимый SIMD на Rust / Zig: оба языка предлагают переносимые векторные API (core::simd в Rust nightly, @Vector в Zig).

Для прикладного разработчика стандартный вход — через переносимую библиотеку (Highway, std::simd, @Vector), что позволяет избежать низкоуровневых интринсиков и сохранить основную часть прироста.

Наше мнение

Хашимото прав: поколение разработчиков, выросшее на управляемых рантаймах (JavaScript, Python, Go), часто не подозревает, что CPU уже десять лет располагает вычислительными средствами, которые их код никогда не использует. Это не обвинение — констатация факта. И отдача, когда наконец подключаешь эти средства к критически важному пути, бывает впечатляющей.

Кратко

• SIMD больше не экзотическая оптимизация: это главный источник оставшихся приростов на CPU.
• Переносимые библиотеки (Highway, std::simd, Zig @Vector) делают вход доступным.
• Всё, что обрабатывает данные в больших объёмах (парсеры, СУБД, изображения, хэши), должно рассматриваться под этим углом.