У вас есть мобильное устройство с процессором RISC-V? Вопрос странноватый, но ответ может быть сложнее, чем кажется. Например, архитектуру RISC-V использует чип безопасности в Google Pixel 6. Конечно, процессоры смартфонов в основном задействуют архитектуру ARM — созданную, кстати, по принципам архитектуры сокращенного набора команд (RISC, Reduced Instruction Set Computer). Зачем же здесь RISC-V? На пятом митапе Российского Альянса RISC-V и YADRO эту тему обсудили эксперты — Сергей Якушкин, Роман Хатько и Антон Афанасьев.
С точки зрения разработки у RISC-V имеется несколько взаимосвязанных преимуществ: открытость, универсальность, большое сообщество и высокие темпы развития. Все больше компаний используют RISC-V, благодаря чему растет ассортимент чипов, быстрее развивается экосистема ПО, а следовательно, снижается и порог входа в архитектуру — что возвращает нас к началу предложения. Модульность RISC-V дает возможность глубокой программно-аппаратной специализации.
Что нужно, чтобы создать мобильное устройство на RISC-V? Готовность самого стандарта, экосистема приложений и экосистема устройств. Международный альянс RISC-V сформировался в 2015 году, а условия для развития мобильного рынка на открытой архитектуре сложились уже к 2021–2022 гг., когда сформировался стандарт для процессоров общего назначения. Рассмотрим этот этап истории подробнее.
Развитие архитектуры RISC-V
После принятия в 2019 году первого RISC-V профиля, RV64GC, события развивались быстро. Примерно в то же время стали появляться первые RISC-V ядра с поддержкой Linux, в том числе российские. В 2021 году вышел планшет на RISC-V с форком Android 10. Через некоторое время команда Android инициировала создание рабочей группы по RISC-V в международном альянсе по развитию ОС. Google официально заявила о приоритетной поддержке архитектуры RISC-V на уровне Tier 1.
В 2023 году приняли профиль RVA22. Планшеты и ноутбуки на RISC-V стали активней появляться на рынке. В это же время Qualcomm и Google анонсировали разработку SoC на RISC-V для платформы носимых устройств Snapdragon Wear.
Активный рост экосистемы привел к принятию следующего профиля RISC-V — RVA23 — уже на следующий год. С ним RISC-V теоретически уже может конкурировать с другими архитектурами в создании открытой бинарной экосистемы, поскольку в RVA23 стали обязательными векторные расширения, появилась поддержка гипервизора и векторной криптографии. Разработка чипов под новые стандарты требует немало времени, поэтому процессоров с поддержкой RVA23 в широкой продаже пока нет и достаточность профиля еще не доказана на практике. Возможно, именно поэтому Google хоть и обозначила, что бинарный интерфейс приложений (ABI) для AOSP будет основан на RVA23, но до сих пор ABI не финализировала.
В 2024 году в продаже появились устройства с поддержкой векторного расширения RVV 1.0. RISE опубликовала гайд по оптимизации на RISC-V, провела адаптацию программных компонентов, запустила бонусную кампанию для разработчиков, портирующих на RISC-V. Canonical заявила, что с версии 25.10 ОС Ubuntu будут собирать под профиль RVA23. А Samsung продемонстрировала телевизор на RISC-V с Tizen.
Сейчас для RISC-V прорабатывают множество новых исследовательских идей и дальнейших расширений. Например, расширение формата команд до 48 и 64 бит, что в некоторых случаях поможет повысить эффективность архитектуры. За счет поддержки новых размеров констант, immediate-операндов и других нововведений в перспективе можно будет уменьшить размер кода. Развивается безопасность векторных расширений, а также расширенное профилирование для анализа сложных приложений, стеков и ПО.
Текущие наработки войдут в профиль RVA30, который, по всей видимости, станет следующим в развитии стандарта. На пути к этому большому обновлению увидит свет ABI для AOSP, а также платформы, определяющие дополнительные требования — например, в серверных сценариях.
Если выяснится, что в RVA23 не хватает каких-нибудь важных обязательных расширений, то придется выпускать новый major-профиль с ними раньше, чем хотелось бы. По пути к нему увидят свет и minor-профили: они содержат только опциональные расширения и не создают проблем с совместимостью.
Адаптация программ под RVA23
Компиляторы, рантаймы и библиотеки нужно адаптировать под RVA23, чтобы они эффективно применяли расширения и конкретные инструкции профиля, обеспечивали высокую производительность и положительный пользовательский опыт. Дистрибутивы должны выпускать сборки под профиль RVA23 — векторное расширение в RVA23 обязательно, и компилятор должен обеспечивать автоматическую векторизацию программ.
Особняком здесь стоят компоненты с кодом, специфичным для конкретных архитектур — на ассемблере, интринсиках. В пакетах исходного кода Debian таковых примерно 4%. Эти компоненты ярко иллюстрируют важность адаптации в мобильных сценариях. Векторный код встречается во множестве компонентов AOSP и Chromium, вот лишь несколько примеров:
Функция memcpy стандартной библиотеки libc в AOSP использует векторный код. Подавление эха, работа с изображениями, преобразование цветовых пространств и так далее — все это также использует векторный код. Для пользовательского опыта важна высокая производительность этих алгоритмов, для чего необходима адаптация исходного кода программных компонентов, а также поддержка компиляторами векторного расширения.
Векторное расширение RVV 1.0
Векторное расширение RVV 1.0, ратифицированное в 2021 году, стало обязательным в RVA23. RVV 1.0 следует концепции VLA (Vector Length Agnostic), поддерживает группировку регистров и маскирование элементов. Разработчик найдет здесь все ожидаемые в векторном расширении инструкции: целочисленную арифметику, floating point, fixed point, разнообразные инструкции доступа в память, редукцию, перестановки и т. д. Но основная идея RVV — это масштабируемость и по длине, и по числу векторных регистров.
Рассмотрим инструкцию настройки конфигурации — она уникальна именно для RVV, и в более традиционных архитектурах с SIMD-подходом такой инструкции нет.
Инструкцию можно представить в разных вариантах. Здесь один аргумент запрашивает вектор длины 21, а другой требует четыре векторных регистра. Софт рассчитан на то, что хоть какое-нибудь число элементов векторного регистра он получит. Масштабируемость здесь налицо, причем в нескольких видах.
Поддержка различных длин векторов выгодна и «железу», и софту. Сравним в этом ракурсе x86 с фиксированной длиной и RISC-V с VLA.
С одной стороны, аппаратно реализовать RVV 1.0 сложнее, накладные расходы больше. Это плата за универсальность. Но с другой стороны, достоинства здесь перевешивают: меньшая фрагментация, бо́льшая масштабируемость, гибкость алгоритмов — и потенциально более компактный векторный код.
С точки зрения экосистем «железа» и ПО векторное расширение RVV 1.0 также имеет преимущества. В черновой версии 0.7.1 спецификация RVV появилась еще в 2019 году. На ней опробовали разные идеи, и через два года увидела свет уже доработанная версия без обратной совместимости с 0.7.1. Вышли чипы Alibaba T-Head, Spacemit, SiFive с RVV 1.0, которая, с другой стороны, появится в Ubuntu 25.10. Так что сегодня софт может рассчитывать на полную поддержку всех инструкций RVV 1.0 на платах с совместимыми чипами.
Что будет после RVV 1.0? Возможен переход сразу к RVV 2.0 без обратной совместимости с RVV 1.0: инструкция будет вместе с конфигурацией, увеличится регистровый файл, будет реализована концепция группировки элементов и аккумулятор вместо widening. Но возможно и инкрементальное развитие, добавление новых и расширение текущих инструкций.
Сейчас сообщество RISC-V с разработчиками ПО активно обсуждает более 120 расширений архитектуры, из которых выбирают оптимальную комбинацию для развития экосистемы. Новые расширения проходят ратификацию и могут быть приняты уже в 2025 году.
И все-таки готов ли RISC-V для мобильных устройств?
В некоторых областях — да, безусловно, и кое-где уже выходит второе поколение таковых. Экосистемы RISC-V уже хватает как минимум для условных «фоторамок» — умных киосков, специализированных планшетов и т. п., где требования к производительности процессора ниже, а набор программного обеспечения ограничен.
Для более сложных устройств — ноутбуков, мобильных телефонов — пока нельзя подтвердить, что RISC-V готова конкурировать с ARM и x86. Многие компании активно развивают это направление: разрабатывают устройства на основе актуального профиля RVA23 и оптимизируют программную экосистему. Устройства с RVA23 и RVV 1.0 анонсируют в сегментах IoT, серверов, появляются процессорные ядра. Поэтому мы с оптимизмом смотрим в будущее и рассчитываем, что распространение RISC-V за пределами «фоторамок» тоже не за горами.
Статья подготовлена по мотивам третьего митапа российского Альянса RISC-V. Запись этого и других докладов вы можете посмотреть на Rutube или Youtube.
Комментарии (20)
checkpoint
11.06.2025 09:49О боже, что они сделали с некогда стройной, выверенной, минималистичной архитектурой.
Зачем вам этот кадавр ? Зачем вам миллиард бесполезных расширений, да еще и обязательных к имплементации ? Почему нельзя остановиться на RV64CG + RVV 1.0, спроектировать и изготовить высокопроизводительный микропроцессор который бы уделал все существующие процы на x86 и ARM ? Кто-то должен остановить этот конгломерат бюрократов!
CodeRush
11.06.2025 09:49Есть мнение, что вся эта вакханалия - это способ заставить и дальше использовать arm64 и x86 на высокопроизводительных системах, потому что иначе как саботажем вот это "развитие" сложно назвать.
Пока что RISC-V отлично себя чувствует у корпораций как замена микро- и нано-ядер, на которых никакой пользовательский код никогда не должен исполняться, а для своих прошивок можно накрутить любые нестандартные расширения, хоть аналог Apple Matrix eXtension, хоть CHERI, хоть PAC, хоть MTE, и при этом не нужно каждый раз в arm чемодан бабла заносить.
checkpoint
11.06.2025 09:49Так и есть, это саботаж. Не даром китайцы послали лесом весь этот сброд и начали пилить свою RISC-X как вариант RISC-V с некоторыми изменениями. Несколько лет назад я еще думал зачем они это делают, ведь это лишает их совместимости с огромной базой софта и компиляторов. Теперь всё стало понятно.
WASD1
11.06.2025 09:49Так профиль (с набором обязательных расширений) - это же наоборот огромный шаг вперёд к унификации.
То есть теперь будет минимальный набор расширений, на наличие которых компилятор может закладываться.
Проблема как раз в том, что профили внедрили слишком поздно и всяких кадавров успели понаделать.checkpoint
11.06.2025 09:49Так профиль (с набором обязательных расширений) - это же наоборот огромный шаг вперёд к унификации.
Вопрос в количестве этих расширений. Подавляющая их часть требуется для очень узконишевых приложений, но обязятельность вынуждает производителей раздувать площадь кристалла, а всех остальных - наращивать кодовую базу (ведь все эти расширения должны поддерживаться в софте). Теряется сам смысл идеи "Reduced Instruction Set Computer" за которую еще совсем недавно боролись сподвижники Паттерсона и Асановича.
Профиль RV64GC был компактный и самодостаточный. Нужно добавить в него RVV и сосредоточить усилия на микроархитекткрных решениях, а не на постоянном наращивании системы команд.
WASD1
11.06.2025 09:49Про площадь - ну допустим (хотя видится, что при реализации по-уму вся эта не критичная по площади комбинаторика будет о-малое занимать). Ну с векторным расширением, насколько я краем уха слышал в RISC-V проблемы.
ведь все эти расширения должны поддерживаться в софте
Э.... а вот это вообще не понял.
Middlewaare (в виде компиляторов, ОС, платформ и библиотек - которое пишется один раз) для того и существует, чтобы писатель конечного софта этим не заморачивался.checkpoint
11.06.2025 09:49Про площадь - ну допустим (хотя видится, что при реализации по-уму вся эта не критичная по площади комбинаторика будет о-малое занимать).
У разработчика цифровой микросхемы каждый вентиль на счету. Не понятно зачем в RVA22 втащили дополнительные битовые манипуляции и еще одну разновидность FP ? Вот это все надо ликвидировать:
• Zba Address computation.
• Zbb Basic bit manipulation.
• Zbs Single-bit instructions.• Zfhmin Half-Precision Floating-point transfer and convert.
Еще там куча всякой дряни для управления сложными кэшами. x86 как-то обходится без этого.
Если прикинуть, вся эта излишняя пурга занимает не мало места.
Ну с векторным расширением, насколько я краем уха слышал в RISC-V проблемы.
Какие, если не секрет ?
Э.... а вот это вообще не понял.Middlewaare (в виде компиляторов, ОС, платформ и библиотек - которое пишется один раз) для того и существует, чтобы писатель конечного софта этим не заморачивался.
И конечный софт и библиотеки придется адаптировать к новым инструкциям. Или Вы полагаете, что достаточно добавить поддержку в компилятор и на этом успокоиться ?
WASD1
11.06.2025 09:49> middleware в виде (1)компиляторов, (2)ОС, (3)платформ и (4)библиотек - которое пишется один раз...
... Или Вы полагаете, что достаточно добавить поддержку в компилятор и на этом успокоиться ?
Это очень плохой способ вести дискуссию ((
========================================Прошу учесть, что RVA профиль не для микроконтроллеров, а для +/- полноценных процессоров, и в мире процессоров многие ваши умолчания могут быть просто не верны: "The RVA20 profiles are intended to be used for 64-bit application processors running rich OS stacks. Only user-mode (RVA20U64) and supervisor-mode (RVA20S64) profiles are specified in this family".
У разработчика цифровой микросхемы каждый вентиль на счету.
Это прям классическое "лучшее враг хорошего" и нездоровый перфикционизм. Выиграть +1% площади для GP CPU - намного менее полезно, чем "заранее потерять 1% пользователей". Потому, что этот 1% неудовлетворённых пользователей всегда будет тянуть вас назад.
Вот про кэши - кажется, что это может добавить довольно много лишней сложности / проблем / аппаратных ошибок. А может быть и "удастся проскочить (типа игнорим все "тонкие" настройки)"- тут судить не берусь, надо прям читать и разбираться - но всё-таки это стандарт для очень гетерогенного набора изделий, а не спека на одно изделие.
> middleware для того и существует, чтобы ISA не проникала в опльзовательский код
И конечный софт и библиотеки придется адаптировать к новым инструкциям
Объясните как вы видите, что наличие дополнительных инструкций влияет на прикладной код (напоминаю RVA - про процессоры, а не микроконтроллеры).
Что интерфейс numpy (или BLAS или pytorch) должен измениться из-за изменения ISA?Векторное расширение проблемы, какие?
Before using the vector unit, we must “configure” itСтейт (длина / битность...), который влияет семантику векторных инструкций.
То есть при выполнении любой векторной инструкции разработчику компилятора следует убедиться, что "стейт" векторного расширения не был изменён (например пользовательский код использует 2 библиотеки для работы с векторами или одна библиотека вызывает другую).
Или даже (глупый, но функционально не запрещённый возможный пример) - работа с векторами в обработчике сигналов?
Вы компилируете библиотеку, а ход трасса кода такая:
1. Настройка стейта векторного расширения
2. Уход в обработчик сигнала, перенастройка стейта векторного расширения
3. Возврат в пользовательский кода и выполнение векторной инструкции с неверный стейтомcheckpoint
11.06.2025 09:49Прошу учесть, что RVA профиль не для микроконтроллеров, а для +/- полноценных процессоров, и в мире процессоров многие ваши умолчания могут быть просто не верны: ...
Спасибо за напоминание.
Объясните как вы видите, что наличие дополнительных инструкций влияет на прикладной код (напоминаю RVA - про процессоры, а не микроконтроллеры).Что интерфейс numpy (или BLAS или pytorch) должен измениться из-за изменения ISA?
Я правильно понимаю, что у Вас процессор общего назначения это вычислитель, который в основном занять инфёренсом нейросеток ? Так вот, поспешу разочаровать, 99.9% приложений в мире - это базы данных и сетевые стеки. Для этих пользователей совершенно класть на специальные возмоности процессора ускоряющие BLAS и pytorch!
И да, реализация BLAS потребует адаптации к новым взможностям процессора.
Или даже (глупый, но функционально не запрещённый возможный пример) - работа с векторами в обработчике сигналов?
Вы правильно прочувствовали суть проблемы, но я немного формализую Ваш ответ.
Основная проблема, с точки зрения ПО, с векторным расширением состоит в том, что оно сильно раздувает контекст, который постоянно требуется сохранять таск-свитчеру при переключении задач и обработки прерываний. В RVV есть некоторый хак позволяющий немного соптимизировать - не сохранять если не было измений состояния, но насколько он эффективен я не знаю. Именно по этой причине я считаю, что векторные вычисления должны быть вынесены в отдельный аппаратный блок, а не интегрированны в основное ядро. Т.е. с точки зрения ОС это должен быть аппартный ресурс, доступ к которому регламентируется специализированным API, по аналогии с GPU, но "потеснее". Подобным образом сделано у Apple M1,2,3.
WASD1
11.06.2025 09:49Спасибо за напоминание.
Ещё одно - так и не подтверждён ваш тезис, что расширение ISA потребует поддержки в прикладном коде.
И да, реализация BLAS потребует адаптации к новым взможностям процессора.
Сначала реализовываем BLAS на "урезанном" (удобном для вас) наборе интринсиков без дополнительных расширений (100% цель достигнута с той же эффективностью и в сроки что и у вас);
А потом ещё и оптимизировать, если получиться, с использованием расширенного набора инструкций - 150% эффективности от вашей реализации.
То есть с строго лучше.Более того: в первом же комментарии было указано, что мiddleware (включая библиотеки) придётся переделывать. С чем вы спорите?
Вы правильно прочувствовали суть проблемы, но я немного формализую Ваш ответ.
Не надо так - это неверная переформулировка.
Во-вторых размер контекста не столь критичен в мире GP CPU (про RVA - это же к тому, чтобы задуматься "что важно что не важно в мире CPU" у вас эти настройки похожи на микроконтроллерные а не CPU-шные).
Проблема в невозможности проводить оптимизации компилятору при любом не статическом вызове (call / ret - с динамически слинкованной библиотекой вообще без шансов, со статически слинкованной - или -lto или дополнительные фазы анализа, без гарантии отсутствия false positive) может измениться контекст.
Именно по этой причине я считаю, что векторные вычисления должны быть вынесены в отдельный аппаратный блок, а не интегрированны в основное ядро.
Не уверен, что это хорошее решение.
У нас уже есть GPU / NPU(скорее зонтичный термин) для тяжеловесных решений.
А для легковесных - latency критически важно. Какое latency и какой ценой сможете обеспечить для 1, 2 или 5 векторных инструкций?
Типовой случай - в цикле делается сколько-то векторных инструкций и "чуть-чуть" дорабатывается не-векторными. Ну и что делать будете?
acc0unt
11.06.2025 09:49"Стройная и минималистичная" - это чтобы похоронить 8051 и Cortex-M0. Для этого как раз максимально урезанные ядра с крохотным списком простых инструкций подходят прекрасно.
Для более тяжёлых применений вроде современных смартфонов, которые должны выполнять безумное количество разных операций кодирования, декодирования и обработки данных, голожопого RISC уже не хватает.
checkpoint
11.06.2025 09:49Можно подробностей каких именно операций не хватает ?
acc0unt
11.06.2025 09:49Да банально, например, GF(2) операции, которыми ускоряют кучу вещей - от обработки изображений и до криптографии.
Это жёсткий уход от идеи RISC - но в ту же сторону, в которую от неё уходят векторные расширения.
Странные инструкции для насилия над битами в процессоры ставят не для красоты, а потому что они полезны для выполнения реальных алгоритмов.
checkpoint
11.06.2025 09:49Да банально, например, GF(2) операции, которыми ускоряют кучу вещей - от обработки изображений и до криптографии.
Во-первых, для криптографии и обработки изображений существуют специализированные процессоры, если Вы вдруг забыли. Основная задача процессора общего назначения - быстро перекладывать массивы данных с места на место и котроллировать права доступа (виртуализация памяти и ресурсов). Во вторых, все битовые операции прекрасно выражаются через две базовых - NAND и NOR, вот их и следует занести в систему команд. Ядра с ортогональной системой команд имеют кратчайшие критические пути, что позволяет разгонять их до умопомрачительных частот. На мой взгляд в этом направлении и следует развиваться, а не в наращивании системы команд и создании "неповоротливых", прожорливых вычислетелей, 90% аппаратуры которых просто простаивает без дела.
Странные инструкции для насилия над битами в процессоры ставят не для красоты, а потому что они полезны для выполнения реальных алгоритмов.
В современном мире полезность и бесполезность определяются прежде всего статистикой. Как часто эти опреции используются ? Какой процент их в смешаном коде ? Как добавление новых операций повлияет на Fmax ? На эти вопросы ответы были даны исследованиями проведенными Паттерсоном и Хеннесси в 1980-х, и повторно в 2010-х. Ответ однозначный: избыточные операции - зло! А если есть свободное место на кристалле, то гораздо эффективнее отдать его под кэш и регистры, а не под навороченные команды. Я даже не уверен, что векторные вычисления должны быть в системе команд. С моей точки зрения их целесообразней выполнить отдельным блоком (отельным вычислителем), пусть даже на том же кристалле. Дело в том, что векторных вычислителей требуется в разы меньше чем обычных многофункциональных ядер, по этому имело бы смысл делать процессоры в виде комбинации из N многофункциональных минималистичных ядер + M векторных, где M << N. big.LITTLE это как раз шаг в данном направлении.
acc0unt
11.06.2025 09:49Процессор не в вакууме существует. На каждую операцию в кремний аппаратный блок не впихнуть. Во-первых в кристалл не влезет, во-вторых завтра новые алгоритмы выйдут и всё равно придётся выполнять их на CPU.
Поэтому гибкость центрального процессора - благо.
Перекладывание данных из DMA в DMA - это работа для ущербного 8051 в узкоспециализированном чипе без даташита. Реальные задачи для процессора в реальном устройстве немного сложнее.
А слепая гонка за Fmax - занятие абсолютно тупое и тупиковое. Что, не научился ничему из истории про AMD Bulldozer?
like_the_sun
Не согласен с несколькоми пунктами таблиц:
меньшая фрагментация ПО: у вас самих написано в статье
Что будет после RVV 1.0? Возможен переход сразу к RVV 2.0 без обратной совместимости с RVV 1.0что несколько противоречитНе вижу особого преимущества профилей над подходом, принятым в x86-64 c инкрементальным (не считая небольших различий в расширениях AMD и Intel) расширением набора инструкций: например добавлением команд для операций над векторным регистром большего размера.
Трудоемкость SW
Для простого алгоритма, как скалярное умножение, да, вектор переменной длины удобен, но большую часть жизни процессоров векторные регистры имели фиксированный размер, что значительно повлияло на алгоритмы, и переход на векторы произвольной длины требует достаточное количество усилий: перенос алгоритма с SSE/AVX на NEON на порядок проще, чем переход с NEON на SVE.
rkhatko
Мне кажется, VLA подход к векторизации лучше отражает ситуацию, когда длины векторов отличаются между процессорами для разных классов устройств. Например, мобильные - 128 bit, настольные - 256 bit, серверные - 512 bit. Причем длина вектора в классе устройств тоже не константа, меняется со временем. Библиотеки же могут использоваться одинаковые, так что требуется поддержать все длины векторов.
Цель у RVV 1.0 амбициозная, ждем высокопроизводительных реализаций.