Почему SIMD не ускорил торговый движок на Rust: ошибки CI и узкие места

Векторизация кода с помощью SIMD (Single Instruction, Multiple Data) часто преподносится как волшебная пилюля для ускорения вычислений. Однако на практике путь от красивых теоретических схем к реальной производительности усеян граблями. Разработчик торгового движка Quince на Rust решил добавить поддержку AVX2 и FMA, ожидая, что VM "полетит". Вместо этого он столкнулся с цепочкой неожиданных узких мест, а финальным аккордом стала ложь CI, показывавшего результаты кода, который процессор даже не исполнял. Это история о том, как не надо оптимизировать и почему вера в чудесные x4 часто разбивается о реальность.

Как SIMD проиграл памяти и кольцевым буферам

Первая попытка ускорить торговую VM заключалась в векторизации операций с четырьмя числами f64 за одну инструкцию. Разработчик добавил AVX2 и FMA, использовал unsafe для прямого вызова intrinsic-функций. Но ожидаемого прироста не произошло. Вместо этого SIMD-версия уступила обычной скалярной реализации. Причина оказалась банальной: узким местом была не арифметика, а доступ к памяти. Торговая VM интенсивно читает и записывает данные в кольцевые буферы, и именно операции с памятью, а не вычисления, доминировали в профиле. SIMD ускорил только малую часть работы, не затронув основного тормоза. Более того, векторизованный код требовал выравнивания данных и дополнительных инструкций для загрузки/выгрузки, что добавляло оверхед.

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

Почему VM съедает ускорение и как CI лжет

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

Но самый обескураживающий момент ждал впереди. CI (Continuous Integration) уверенно показывал ускорение в 2-3 раза на синтетических тестах. Однако когда разработчик запустил те же бенчмарки локально с отключенной оптимизацией, цифры совпали с CI. Включив оптимизацию, он получил... падение производительности. Оказалось, что CI собирал код с флагом debug, а не release. Компилятор Rust в debug-режиме не применяет автовекторизацию и не оптимизирует скалярный код, поэтому SIMD-версия действительно была быстрее. В release-сборке компилятор сам векторизовал скалярный цикл, и ручная SIMD-реализация не давала преимущества, а из-за оверхеда даже проигрывала. CI, настроенный на быструю проверку, использовал debug-профиль, и его результаты были полностью недостоверны.

Кого затронет и как

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

Для пользователей Quince и подобных систем этот инцидент означает, что разработчики стали осторожнее относиться к обещаниям "волшебных ускорений". Вместо этого они сосредоточились на оптимизации памяти и архитектуры VM, что дало реальный прирост. Для сообщества Rust это еще одно напоминание о том, что unsafe и intrinsic-функции требуют не только знаний, но и тщательного тестирования в реальных условиях, а CI должен быть настроен на профиль, соответствующий production-сборке.

Как избежать ошибок при оптимизации с SIMD на Rust

Первый шаг — всегда профилировать до начала оптимизации. Используйте инструменты вроде perf, flamegraph или Valgrind, чтобы выявить истинные узкие места. В случае с Quince профилирование показало бы, что основное время тратится на доступ к памяти, а не на арифметику. Второй шаг — настраивать CI так, чтобы бенчмарки запускались в release-профиле с теми же флагами, что и production. Это кажется очевидным, но многие проекты пренебрегают этим, экономя время сборки. Третий шаг — проверять, что данные выровнены и упакованы. Используйте repr(C) или выравнивание с помощью alignto. Четвертый шаг — не забывать, что компиляторы Rust умеют автоматически векторизовать простые циклы, и ручная реализация может быть не нужна. Всегда сравнивайте ручную SIMD с автовекторизованным скалярным кодом.

Что будет дальше

Разработчик Quince опубликовал подробный отчет о своих экспериментах, включая код и бенчмарки. Он планирует переработать VM, чтобы сделать ее более дружественной к векторизации: перейти на непрерывные массивы структур вместо структур массивов, уменьшить накладные расходы интерпретатора. Также он намерен добавить в CI отдельную задачу с профилем release для бенчмарков. В более широком смысле эта история стимулирует дискуссию о том, когда SIMD действительно нужен, а когда достаточно довериться компилятору. Вероятно, многие проекты пересмотрят свои оптимизационные стратегии, уделяя больше внимания профилированию и меньше — модным техникам.

Итог

Векторизация — мощный инструмент, но не панацея. История с Quince показывает, что без глубокого понимания узких мест, архитектуры и настроек CI можно потратить недели на оптимизацию, которая не даст результата. Главные уроки: профилируйте до оптимизации, не верьте CI, если он не соответствует production-сборке, и помните, что SIMD ускоряет вычисления, но не работу с памятью. Торговый движок в итоге не полетел, но его создатель получил бесценный опыт, которым поделился с сообществом.