Архитектура RISC-V активно развивается, и поддержка профиля RVA23 с векторным расширением RVV 1.0 становится ключевым маркером зрелости платформы. Одной из первых систем, демонстрирующих этот потенциал, стала плата SpacemiT K3 (Pico ITX). В данном материале мы разберем результаты тестирования производительности RVV 1.0 на базе 16-ядерного чипа с ядрами X100/A100, чтобы понять, дает ли векторизация реальный прирост в современных рабочих нагрузках.
01Железо и программный стек
Тестирование проводилось на эталонной системе SpacemiT K3 Pico ITX. Это однокристальная система (SoC), поддерживающая профиль RVA23, что подразумевает наличие векторных инструкций. Конфигурация тестового стенда следующая:
- Процессор: SpacemiT K3 (16 ядер, архитектура X100/A100).
- Оперативная память: 16 ГБ.
- ОС: Bianbu 4.0 (дистрибутив на базе Linux).
- Ядро: Linux 6.18.
- Компилятор: GCC 15.2.
02Проблема runtime-отключения RVV
Идеальный сценарий сравнения «с RVV» и «без RVV» на одном и том же железе предполагает возможность динамического отключения расширения. В документации kernel.org описан интерфейс /proc/sys/abi/riscv_v_default_allow, который теоретически позволяет переключать поддержку RVV на лету.
Однако на практике этот метод оказался неприменимым. При попытке отключить поддержку RVV через этот sysfs-интерфейс система становилась полностью неработоспособной. Это произошло из-за того, что базовые библиотеки (libc) в дистрибутиве Bianbu 4.0 были скомпилированы с использованием безусловных векторных инструкций RVV. Как только флаг отключался, любая попытка запуска бинарного файла приводила к ошибке illegal instruction.
Это подчеркивает критическую зависимость современных RISC-V дистрибутивов от наличия векторных инструкций в базовом стеке. Для корректного сравнения пришлось прибегнуть к ручному пересборке пакетов с отключением опций компиляции, связанных с RVV, что является более трудоемким процессом, чем простое переключение бита в CPUID, как это бывает с AVX-512 в x86.
03Методология тестирования
Поскольку runtime-отключение не сработало, сравнение производительности проводилось путем компиляции тестовых пакетов в двух конфигурациях:
- RVV Enabled: Стандартная сборка с поддержкой векторных расширений RVV 1.0.
- RVV Disabled: Сборка с отключенными патчами и флагами компилятора, отвечающими за генерацию векторного кода.
Тестировались различные приложения, использующие векторные вычисления. Основной фокус был сделан на том, насколько сильно оптимизатор GCC 15.2 умеет использовать доступные векторные регистры для ускорения вычислений по сравнению с scalar-кодом.
04Результаты производительности
Хотя детальные графики по каждому бенчмарку требуют отдельного разбора, общий вывод тестов SpacemiT K3 демонстрирует значительный прирост производительности при включенном RVV 1.0. В задачах, чувствительных к пропускной способности памяти и векторным операциям (математические вычисления, обработка изображений, криптография), ускорение было наиболее заметным.
Архитектура X100/A100 в составе K3 позволяет эффективно распараллеливать данные. Векторные инструкции RVV 1.0 позволяют обрабатывать несколько элементов данных за один такт, что критически важно для достижения высокой производительности на 16 ядрах. Без RVV процессор вынужден выполнять те же задачи в scalar-режиме, что приводит к увеличению количества инструкций и, как следствие, к снижению FPS или увеличению времени выполнения.
Для практиков важно отметить, что прирост зависит от типа нагрузки. В задачах, ограниченных задержками памяти (memory-bound), векторизация дает меньший эффект, чем в вычислительно сложных (compute-bound) задачах, где можно полностью загрузить векторные ALU.
05Что запустится и кому это нужно
SpacemiT K3 с RVV 1.0 — это пример современного RISC-V решения, которое уже сейчас способно конкурировать по производительности в специфичных задачах с более старыми x86/ARM платформами, особенно с учетом роста экосистемы.
- Для разработчиков RISC-V: Платформа необходима для отладки и оптимизации кода, использующего RVV 1.0. Наличие реальных бенчмарков помогает калибровать компиляторы (GCC/LLVM).
- Для энтузиастов: Это возможность потрогать «будущее» RISC-V. Однако из-за проблем с совместимостью базовых библиотек при отключении RVV, система требует аккуратного подхода к выбору ПО. Не все программы будут работать, если они скомпилированы с жесткой зависимостью от векторных инструкций.
- Для бизнеса: Если вы рассматриваете RISC-V для edge-вычислений, убедитесь, что ваш стек ПО (особенно libc и ключевые библиотеки) поддерживает RVV. В противном случае вы рискуете получить неработоспособную систему при обновлении дистрибутива.
SpacemiT K3 показывает, что RISC-V перешел от стадии прототипирования к стадии практического использования с полноценной поддержкой современных расширений. Однако экосистема все еще требует доработки в части гибкости конфигурации (runtime toggling) и совместимости бинарных файлов.
Источник: Phoronix ↗