Комитет C++ выпустил стандарт C++26 с функцией std::simd из стандартизации P1928. Идея звучит заманчиво: напиши код раз и собери для AVX2, AVX-512, NEON или SVE. Никакого спaghetti с #ifdef __AVX512F__ и интринси. Достаточно std::simd<float>, а компилятор всё решит. Однако сатирический репозиторий от NoNaeAbC недавно перечислил шесть реальных причин отказаться от этой технологии, подтвердив каждый пункт бенчмарками. Сборка занимает в 10 раз дольше, выполнение медленнее обычных скалярных циклов, по умолчанию используется не тот размер вектора, а выражать нужные для реальных задач операции нельзя. Авто-векторизатор компилятора, который std::simd должен был заменить, побеждает по всем важным метрикам.
История началась с Маттиаса Кретца из GSI в Дармштадте. В 2009–2010 годах он создал библиотеку Vc для параллелизации симуляций физики высоких энергий. Проект был серьёзным: более 5000 коммитов, его использовали в CERN. Кретц предложил передать свои идеи в комитет C++. Путь стандартизации занял почти десять лет. Сначала это был технический спецификацию Parallelism TS 2, потом экспериментальная версия в GCC 11. Но к моменту выхода в C++26 ландшафт изменился. Авто-векторизаторы GCC, Clang и MSVC сильно улучшились. ISPC показал, что языковые уровни работают лучше библиотек. ARM запустила SVE — масштабируемую ширину, которая ломает фиксированные абстракции. Компилятор стал умно векторизовать скалярные циклы автоматически.
Пока std::simd глотал бюрократию, экосистема открытого кода не ждала. Google разработала Highway для своих кодеков, которая умеет динамически подбирать реализацию под процессор без пересборки. В отличие от неё, std::simd не знает про динамический выбор. Google использовала свои решения, а не стандартную библиотеку. Есть и SIMDe, который переводит интринсики Intel на ARM, и xsimd, и EVE. Но EVE, созданный участником комитета Джоэлем Фальку, тоже страдает от тех же проблем. Это всё ещё библиотека с прозрачным для оптимизатора кодом. В библиотеке VCL от Agner Foga вообще нет поддержки ARM. А ISPC решает задачу на уровне языка и генерирует лучший код.
Причины проблем фундаментальны. Шаблонный код закрывает доступ оптимизатору. Скалярный цикл с sin компилируется в 0.2 секунды, а версия через std::simd — в 2.2 секунды. На машине с регистрами 512 бит библиотека по-прежнему использует 128 бит, что делает её в 2.4 раза медленнее простого цикла. На ARM она вообще не использует масштабируемые инструкции SVE. Библиотека не поддерживает критичные перестановки данных, необходимые кодекам вроде ffmpeg, и наследует проблемы языка, например промотацию целых типов, ломающую работу с 8-битными пикселями. Есть и проблема с выравниванием, которую компилятор не видит через границы функций.
Комитет выбрал путь библиотеки, но это решение не имеет шансов на успех в 2026 году. Авто-векторизатор справляется с простыми случаями, а для сложных операций нужны интринсики. std::simd занимает неудобное место посередине: слишком высокоуровневый для тех, кому нужны детали, и слишком низкоуровневый для тех, кто ищет абстракцию. Для производительных систем остаётся стратегия: используем интринсики там, где нужно точное управление, а авто-векторизатор берёт остальное. C++26 это не меняет.