Комментарии 22
Не согласен с несколькоми пунктами таблиц:
меньшая фрагментация ПО: у вас самих написано в статье
Что будет после RVV 1.0? Возможен переход сразу к RVV 2.0 без обратной совместимости с RVV 1.0что несколько противоречитНе вижу особого преимущества профилей над подходом, принятым в x86-64 c инкрементальным (не считая небольших различий в расширениях AMD и Intel) расширением набора инструкций: например добавлением команд для операций над векторным регистром большего размера.
Трудоемкость SW
Для простого алгоритма, как скалярное умножение, да, вектор переменной длины удобен, но большую часть жизни процессоров векторные регистры имели фиксированный размер, что значительно повлияло на алгоритмы, и переход на векторы произвольной длины требует достаточное количество усилий: перенос алгоритма с SSE/AVX на NEON на порядок проще, чем переход с NEON на SVE.
Мне кажется, VLA подход к векторизации лучше отражает ситуацию, когда длины векторов отличаются между процессорами для разных классов устройств. Например, мобильные - 128 bit, настольные - 256 bit, серверные - 512 bit. Причем длина вектора в классе устройств тоже не константа, меняется со временем. Библиотеки же могут использоваться одинаковые, так что требуется поддержать все длины векторов.
Цель у RVV 1.0 амбициозная, ждем высокопроизводительных реализаций.
О боже, что они сделали с некогда стройной, выверенной, минималистичной архитектурой.
Зачем вам этот кадавр ? Зачем вам миллиард бесполезных расширений, да еще и обязательных к имплементации ? Почему нельзя остановиться на RV64CG + RVV 1.0, спроектировать и изготовить высокопроизводительный микропроцессор который бы уделал все существующие процы на x86 и ARM ? Кто-то должен остановить этот конгломерат бюрократов!
Есть мнение, что вся эта вакханалия - это способ заставить и дальше использовать arm64 и x86 на высокопроизводительных системах, потому что иначе как саботажем вот это "развитие" сложно назвать.
Пока что RISC-V отлично себя чувствует у корпораций как замена микро- и нано-ядер, на которых никакой пользовательский код никогда не должен исполняться, а для своих прошивок можно накрутить любые нестандартные расширения, хоть аналог Apple Matrix eXtension, хоть CHERI, хоть PAC, хоть MTE, и при этом не нужно каждый раз в arm чемодан бабла заносить.
Так профиль (с набором обязательных расширений) - это же наоборот огромный шаг вперёд к унификации.
То есть теперь будет минимальный набор расширений, на наличие которых компилятор может закладываться.
Проблема как раз в том, что профили внедрили слишком поздно и всяких кадавров успели понаделать.
Так профиль (с набором обязательных расширений) - это же наоборот огромный шаг вперёд к унификации.
Вопрос в количестве этих расширений. Подавляющая их часть требуется для очень узконишевых приложений, но обязятельность вынуждает производителей раздувать площадь кристалла, а всех остальных - наращивать кодовую базу (ведь все эти расширения должны поддерживаться в софте). Теряется сам смысл идеи "Reduced Instruction Set Computer" за которую еще совсем недавно боролись сподвижники Паттерсона и Асановича.
Профиль RV64GC был компактный и самодостаточный. Нужно добавить в него RVV и сосредоточить усилия на микроархитекткрных решениях, а не на постоянном наращивании системы команд.
Про площадь - ну допустим (хотя видится, что при реализации по-уму вся эта не критичная по площади комбинаторика будет о-малое занимать). Ну с векторным расширением, насколько я краем уха слышал в RISC-V проблемы.
ведь все эти расширения должны поддерживаться в софте
Э.... а вот это вообще не понял.
Middlewaare (в виде компиляторов, ОС, платформ и библиотек - которое пишется один раз) для того и существует, чтобы писатель конечного софта этим не заморачивался.
Про площадь - ну допустим (хотя видится, что при реализации по-уму вся эта не критичная по площади комбинаторика будет о-малое занимать).
У разработчика цифровой микросхемы каждый вентиль на счету. Не понятно зачем в 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 (в виде компиляторов, ОС, платформ и библиотек - которое пишется один раз) для того и существует, чтобы писатель конечного софта этим не заморачивался.
И конечный софт и библиотеки придется адаптировать к новым инструкциям. Или Вы полагаете, что достаточно добавить поддержку в компилятор и на этом успокоиться ?
> 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. Возврат в пользовательский кода и выполнение векторной инструкции с неверный стейтом
Прошу учесть, что RVA профиль не для микроконтроллеров, а для +/- полноценных процессоров, и в мире процессоров многие ваши умолчания могут быть просто не верны: ...
Спасибо за напоминание.
Объясните как вы видите, что наличие дополнительных инструкций влияет на прикладной код (напоминаю RVA - про процессоры, а не микроконтроллеры).Что интерфейс numpy (или BLAS или pytorch) должен измениться из-за изменения ISA?
Я правильно понимаю, что у Вас процессор общего назначения это вычислитель, который в основном занять инфёренсом нейросеток ? Так вот, поспешу разочаровать, 99.9% приложений в мире - это базы данных и сетевые стеки. Для этих пользователей совершенно класть на специальные возмоности процессора ускоряющие BLAS и pytorch!
И да, реализация BLAS потребует адаптации к новым взможностям процессора.
Или даже (глупый, но функционально не запрещённый возможный пример) - работа с векторами в обработчике сигналов?
Вы правильно прочувствовали суть проблемы, но я немного формализую Ваш ответ.
Основная проблема, с точки зрения ПО, с векторным расширением состоит в том, что оно сильно раздувает контекст, который постоянно требуется сохранять таск-свитчеру при переключении задач и обработки прерываний. В RVV есть некоторый хак позволяющий немного соптимизировать - не сохранять если не было измений состояния, но насколько он эффективен я не знаю. Именно по этой причине я считаю, что векторные вычисления должны быть вынесены в отдельный аппаратный блок, а не интегрированны в основное ядро. Т.е. с точки зрения ОС это должен быть аппартный ресурс, доступ к которому регламентируется специализированным API, по аналогии с GPU, но "потеснее". Подобным образом сделано у Apple M1,2,3.
Спасибо за напоминание.
Ещё одно - так и не подтверждён ваш тезис, что расширение ISA потребует поддержки в прикладном коде.
И да, реализация BLAS потребует адаптации к новым взможностям процессора.
Сначала реализовываем BLAS на "урезанном" (удобном для вас) наборе интринсиков без дополнительных расширений (100% цель достигнута с той же эффективностью и в сроки что и у вас);
А потом ещё и оптимизировать, если получиться, с использованием расширенного набора инструкций - 150% эффективности от вашей реализации.
То есть с строго лучше.
Более того: в первом же комментарии было указано, что мiddleware (включая библиотеки) придётся переделывать. С чем вы спорите?
Вы правильно прочувствовали суть проблемы, но я немного формализую Ваш ответ.
Не надо так - это неверная переформулировка.
Во-вторых размер контекста не столь критичен в мире GP CPU (про RVA - это же к тому, чтобы задуматься "что важно что не важно в мире CPU" у вас эти настройки похожи на микроконтроллерные а не CPU-шные).
Проблема в невозможности проводить оптимизации компилятору при любом не статическом вызове (call / ret - с динамически слинкованной библиотекой вообще без шансов, со статически слинкованной - или -lto или дополнительные фазы анализа, без гарантии отсутствия false positive) может измениться контекст.
Именно по этой причине я считаю, что векторные вычисления должны быть вынесены в отдельный аппаратный блок, а не интегрированны в основное ядро.
Не уверен, что это хорошее решение.
У нас уже есть GPU / NPU(скорее зонтичный термин) для тяжеловесных решений.
А для легковесных - latency критически важно. Какое latency и какой ценой сможете обеспечить для 1, 2 или 5 векторных инструкций?
Типовой случай - в цикле делается сколько-то векторных инструкций и "чуть-чуть" дорабатывается не-векторными. Ну и что делать будете?
"Стройная и минималистичная" - это чтобы похоронить 8051 и Cortex-M0. Для этого как раз максимально урезанные ядра с крохотным списком простых инструкций подходят прекрасно.
Для более тяжёлых применений вроде современных смартфонов, которые должны выполнять безумное количество разных операций кодирования, декодирования и обработки данных, голожопого RISC уже не хватает.
Можно подробностей каких именно операций не хватает ?
Да банально, например, GF(2) операции, которыми ускоряют кучу вещей - от обработки изображений и до криптографии.
Это жёсткий уход от идеи RISC - но в ту же сторону, в которую от неё уходят векторные расширения.
Странные инструкции для насилия над битами в процессоры ставят не для красоты, а потому что они полезны для выполнения реальных алгоритмов.
Да банально, например, GF(2) операции, которыми ускоряют кучу вещей - от обработки изображений и до криптографии.
Во-первых, для криптографии и обработки изображений существуют специализированные процессоры, если Вы вдруг забыли. Основная задача процессора общего назначения - быстро перекладывать массивы данных с места на место и котроллировать права доступа (виртуализация памяти и ресурсов). Во вторых, все битовые операции прекрасно выражаются через две базовых - NAND и NOR, вот их и следует занести в систему команд. Ядра с ортогональной системой команд имеют кратчайшие критические пути, что позволяет разгонять их до умопомрачительных частот. На мой взгляд в этом направлении и следует развиваться, а не в наращивании системы команд и создании "неповоротливых", прожорливых вычислетелей, 90% аппаратуры которых просто простаивает без дела.
Странные инструкции для насилия над битами в процессоры ставят не для красоты, а потому что они полезны для выполнения реальных алгоритмов.
В современном мире полезность и бесполезность определяются прежде всего статистикой. Как часто эти опреции используются ? Какой процент их в смешаном коде ? Как добавление новых операций повлияет на Fmax ? На эти вопросы ответы были даны исследованиями проведенными Паттерсоном и Хеннесси в 1980-х, и повторно в 2010-х. Ответ однозначный: избыточные операции - зло! А если есть свободное место на кристалле, то гораздо эффективнее отдать его под кэш и регистры, а не под навороченные команды. Я даже не уверен, что векторные вычисления должны быть в системе команд. С моей точки зрения их целесообразней выполнить отдельным блоком (отельным вычислителем), пусть даже на том же кристалле. Дело в том, что векторных вычислителей требуется в разы меньше чем обычных многофункциональных ядер, по этому имело бы смысл делать процессоры в виде комбинации из N многофункциональных минималистичных ядер + M векторных, где M << N. big.LITTLE это как раз шаг в данном направлении.
Процессор не в вакууме существует. На каждую операцию в кремний аппаратный блок не впихнуть. Во-первых в кристалл не влезет, во-вторых завтра новые алгоритмы выйдут и всё равно придётся выполнять их на CPU.
Поэтому гибкость центрального процессора - благо.
Перекладывание данных из DMA в DMA - это работа для ущербного 8051 в узкоспециализированном чипе без даташита. Реальные задачи для процессора в реальном устройстве немного сложнее.
А слепая гонка за Fmax - занятие абсолютно тупое и тупиковое. Что, не научился ничему из истории про AMD Bulldozer?
Кто нибудь может сосчитать общее число команд входящих в RVA23 ?
Интересно, возможна ли ситуация когда из огромного количества расширений и вариантов мы придём к какому-нибудь одному наиболее эффективному?
Или все будут сидеть в своих уникальных расширениях?
Думаю что сейчас ещё допустимо выпускать RVV без обратной совместимости, так как конечный пользователь вряд ли пострадает, возможно он даже и не заметит. Тут писали про фоторамки, действительно какая разница, что там происходит внутри устройства, в котором не будет обновлений после выпуска или произвел и забыли. А вот когда появиться хоть какой-то пользовательская база, где софт не будет поддерживаться, то тут проблемы могут возникнуть. С другой стороны, никто не мешает грубо говоря игнорировать старый софт. Проблемы возможны когда у вас условная игра (пример большой, сложной, до максимума оптимизированной программы под архитектуру), пользовательская база в миллионы и выходит новый обратно не совместимый процессор, на который в среднем за 7 лет перейдут пользователи. А пользователь не хочет терять возможность играть в условную игру.
Массово нужны коробочные решения, включил и забыл, чтобы при покупке второго поколения коробки, всё что было в первой работало во второй, без существенной потери.
А пока у нас эпоха экспериментов.
Если устройство с закрытым программным стеком (весь код собирается под конкретное устройство), то можно отобрать оптимальный набор расширений под конкретную задачу. Это сильная сторона RISC-V, позволяющая выпускать специализированные процессоры.
Если требуется открытая бинарная экосистема программ (пример с игрой), то RVI предлагает ориентироваться на Major RVA профили (сейчас это RVA23). Следующий RVA профиль (предположительно - RVA30) будет содержать новые обязательные расширения.
Предположу, что собранные под RVA23 программы запустятся на RVA30. То есть, mandatory расширения в новом профиле не будут исключать. Тогда условная игра под RVA23 запустится на новом RVA30 процессоре.
Рекомендую - RISC-V State of the Union - Krste Asanović (YouTube)
Какие сценарии не покрываются таким подходом?
Готовность RISC-V для мобильных устройств: чекап середины 2025 года