Рост популярности RISC-V с момента его появления в 2010 году позволяет говорить, что архитектура состоялась. Можно отметить два наиболее ярких примера.

Первый. Китай создает на базе  RISC-V свой форк RISC-X. Он будет, как и RISC-V, открытым и доступным всем странам альянса «Один пояс и один путь». Создание этого форка повышает надежность и устойчивость китайского IT сектора при потенциально возможных санкциях и других неблагоприятных сценариях.

Второй. Правительство Индии анонсировало программу Digital India RISC-V Microprocessor Program (DIR-V), которая координирует совместную разработку промышленными и научными институтами страны микропроцессоров для серверов, мобильных устройств, автомобилей, микроконтроллеров различного назначения и устройств Интернета вещей на базе RISC-V.

Пока успех архитектуры RISC-V — это, в первую очередь, ее открытость. Все остальные факторы вторичны. Минимализм системы команд, ее стандартизация, программная инфрастуктура — все это очень важно. Но, если бы за все это платили, как платят создателям ARM, то RISC-V, скорее всего, не было бы. Говорить о действительном успехе этой архитектуры можно будет только тогда, когда она создаст реальную конкуренцию ARM и х86 на высокомаржинальных рынках мобильных телефонов, планшетов, ПК, встроенных систем, суперкомпьютеров и искусственного интеллекта.

Открытость архитектуры важна для стартапов и небольших компаний. Для компаний, которые доминируют на этих рынках, важны другие характеристики. И, в первую очередь, это производительность, энергопотребление и цена процессоров.

ARM тоже начинал с небольшой, в несколько десятков операций, системы команд. Современный ARMv8 имеет около 1000 команд + суперскалярность. Это все — плата за производительность. Подобный путь должна будет пройти и архитектура RISC-V, чтобы выйти на эти рынки.

Существующие реализации  RISC-V — это, как правило, микроконтроллеры. Например, как микропроцессор MIK32, созданный АО «Микрон».

Микропроцессор MIK32, созданный АО «Микрон»

Уровень микроконтроллера явно не та цель, которая ставилась при создании RISC-V. Это понимают и авторы, и пользователи архитектуры. Практически из всех материалов по RISC-V следует вывод о необходимости сильного смещения в сторону суперскалярных ядер. С одной стороны, это ожидаемо, поскольку такой способ повышения производительности соответствует идеологии RISC, однако, с другой стороны, такой подход выглядит как лоббирование определенных технических решений.

Как известно, суперскалярность — это способность процессора выявить и реализовать в процессе исполнения программы тот параллелизм, который присутствует в ее последовательном коде. Инструменты, которые обеспечивают решение этой задачи — достаточно известны. Основные из них — это предсказание переходов, внеочередное исполнение команд, предикативные команды. Работы в этом направлении для RISC-V ведутся.

Известно также, что суперскаляр — это очень сложно. Нельзя не согласиться тем, что:

Беда не в самом суперскаляре, а в представлении программ. Программы представлены последовательно, и их нужно во время исполнения преобразовывать в параллельное выполнение. Главная проблема суперскаляра – в неприспособленности входного кода к его нуждам. Имеется параллельный алгоритм работы ядра и параллельно организованная аппаратная часть. Однако между ними, по середине, находится некая бюрократическая организация – последовательная система команд. Компилятор преобразует программу в последовательную систему команд; от той последовательности, в какой он это сделает, будет зависеть общая скорость процесса. Но компилятор не знает в точности, как работает машина. Поэтому, вообще говоря, работа компилятора сегодня – это шаманство. Он просто смотрит: «если так переставить, то быстрее будет». Наверное.

Но, все упорно идут по этому пути. Сначала одна, очень квалифицированная группа программистов, плохих на этой работе не держат, создает backend фазу компилятора, долго и упорно «вылизывая» код, добиваясь минимума команд. При этом тот параллелизм, который изначально виден в исходном коде на языке высокого уровня, после backend увидеть крайне сложно. Потом, другая не менее квалифицированная группа, но уже инженеров, делают все, чтобы из этого последовательного оптимизированного кода увидеть (хотя бы частично) и реализовать на лету в процессоре тот параллелизм, который был в исходном коде.

Альтернативный подход это отказ от последовательного фон-неймановского кода. Сохранение в откомпилированной программе всего параллелизма, присутствующего в исходном коде. Это обеспечивается мультиклеточными принципами организации вычислительного процесса (мультиклеточной архитектурой).

Подробнее о мультиклеточной архитектуре

Мультиклеточная архитектура — принципиально новая, патентно-защищенная, не-фон-неймановская архитектура, обеспечивающая автоматическую реализацию параллелизма в процессе выполнения программы. Архитектура апробирована (выпущено три процессора), которые применялись в ряде приборов. Отличается высокой производительностью и низким энергопотреблением (подробнее: Мультиклет R1 — первые тесты, Мультиклет стал еще доступнее и Мультиклеточная архитектура: тесты и развитие).

Мультиклеточная архитектура может быть использована не только на архитектурном уровне процессора доступном компилятору и программисту, но и на микроархитектурном уровне.

Так, если уровень системы команд RISC-V рассматривать как архитектурный, доступный компилятору и программисту, то реализация этого уровня внутри процессора на мультиклеточных принципах будет микроархитектурным уровнем, недоступным программисту, но именно этот уровень отвечает за характеристики процессора.

В этом случае, поток команд RISC-V, выбираемый из памяти, декодируется в поток микрокоманд для мультиклеточнго ядра, например состоящего из 4-16 клеток, и выполняется на микроархитектурном уровне. Так, для восьмиклеточного ядра:

  1. Блоки выборки и декодирования клеток выполняют выборку до 8 команд за такт. Выборка осуществляется независимо от процесса исполнения ранее выбранных команд, до выборки команды перехода;

  2. Микрокоманды, полученные после декодирования, тегируются (определяются теги требуемых операндов, устанавливается тег микрокоманды, который является тегом ее результата), и поступают в буферные устройства клеток, где хранятся до исполнения;

  3. Микрокоманда исполняется по готовности, когда в массив результатов клетки придут все необходимые ей результаты с тегами требуемых операндов. Результат выполнения микрокоманды с ее тегом также поступает в массивы результатов клеток;

  4. Клетки синхронизируются только процессе выборки и декодирования. Исполнение микрокоманд не синхронизировано. Каждая клетка на этом этапе работает независимо от других;

  5. В целом, мультиклеточное ядро работает как система массового обслуживания. Глобального конвейера нет. Внутри каждой клетки конвейеризировано только исполнение операций;

  6. Регистры общего назначения отображаются на локальную память и используются на общих основаниях, как локальные переменные;

  7. Латентность прерывания — нулевая, так как нет общего ресурса у прерываемой и прерывающей программ в виде поля регистров;

  8. Переход осуществляется при вычислении адреса перехода, независимо от завершения ранее выбранных команд.

В результате предлагаемая микроархитектура обеспечивает полный аналог суперскалярного режима работы процессора. А именно:

  • осуществляется одновременная выборка  и последующее параллельное исполнение до 8 команд;

  • команды выполняются вне очереди;

  • в подавляющем большинстве случаев выборка и исполнение команд перехода очередного линейного участка осуществляется еще до завершения предыдущего, что позволяет отказаться от механизмов предсказания перехода.

Предсказание переходов — ключевой механизм в традиционном подходе к реализации суперскалярности. Современные микропроцессоры используют все более сложные алгоритмы предсказания. Хотя в существующих блоках предсказаний все еще можно получить решение за один такт, недавние исследования показывают, что повышение, в перспективе, тактовой частоты потребует многоциклового доступа к таблицам прогнозирования ветвлений. Таким образом, будущие предсказатели переходов должны учитывать не только площадь, точность и энергопотребление, но и задержку.

Высокая точность прогнозирования ветвлений, необходимая для высокой производительности, достигается за счет больших таблиц прогнозирования ветвлений и / или (как уже отмечалось) более сложных алгоритмов прогнозирования. И большие таблицы и сложные алгоритмы требуют большей площади чипа и имеют более высокое энергопотребление, что практически исключает их использование во встраиваемых процессорах.

Так, по оценке инженеров компании AMD затраты кремния на организацию суперскалярного вычисления в три и более раз превосходят затраты на собственно реализацию системы команд семейства х86, включающей около 2000 команд. В мультиклеточной микроархитектуре эти затраты сравнимы с затратами на реализацию команд RISC-V. Таким образом, высвобождается кремниевый ресурс, который может быть использован в различных целях.

Характеристики мультиклеточных ядер в сравнении с Intel Kaby Lake, NVIDIA RTX и AMD Radeon

В 2020 году компанией «Мультиклет» был проведен ряд семинаров с техническими специалистами компании AMD по мультиклеточной архитектуре, на которых она получила высокую оценку.

Анализировались ECAD оценки  мультиклетки процессора MultiClet S1 и одного суперскалярного ядра Intel Kaby Lake. Мультиклетка — это аналог суперскалярного RISC процессора с выборкой за один такт до 4-х команд. Суперскалярное ядро Intel Kaby Lake за один такт выбирает до 6-ти CISC команд, каждая из которых, в свою очередь, декодируется в группу до 6-ти RISC команд.

Характеристики мультиклетки и ядра приведены в таблице 1.

Таблица 1.

Процессор

MultiClet S1

1 ядро
Intel Kaby Lake

Частота

2000 МГц

4500 МГц

Энергопотребление

0.14 W

7 W

Площадь
(14 нм)

0.23 мм2

9.5 мм2

Количество команд выбираемых за один такт CISC (RISC)

2(4)

6 (36)

Данные по времени выполнения тестов приведены в таблице 2.

Таблица 2.

Тест

Мультиклетка
(4 клетки)
MultiClet S1, такты

1 ядро
Intel Kaby Lake,
такты

Бинарное дерево
(глубина 6)

1167671

247511

8 ферзей

3510425

700389

Мандельброт (32х32)

1164781

301888

Драйстоун
(200 циклов)

146076

17400

Сравнительная оценка данных приведенных в табл. 1,2 показывает, что несмотря на то, что абсолютное время время решения задач мультиклеткой больше, ее удельные характеристики, для всех тестов, по отношению к энергопотреблению в разы лучше, чем  характеристики  ядра Intel Kaby Lake.

Аналогичные данные были получены и при оценке алгоритма подсчета хэшей Ethash (см. таблицу 3).

Таблица 3.

Устройство

Хэшрейт

TDP

Хэшрейт/TDP

Техпроцесс

Плата-ускоритель
с 16
MultiClet S1

62 MHash/s

50 W

1.24

7 нм

Плата-ускоритель с 16 MultiClet S1

52 MHash/s

84 W

0.62

28 нм

NVIDIA 90HX

86 MHash/s

320 W

0.27

7 нм

NVIDIA RTX 2080 Ti

52.5 MHash/s

180 W

0.29

12 нм

AMD Radeon RX 5700 XT

51.5 MHash/s

150 W

0.34

7 нм

AMD Radeon RX Vega 64

46 MHash/s

200 W

0.23

14 нм

Дополнительный кремниевый ресурс, который образуется при использовании мультиклеточной микроархитектуры, может быть использован для:

  • уменьшения площади процессора и, соответственно, цены процессора;

  • уменьшения энергопотребления;

  • увеличения объемов внутрикристальной памяти и, как следствие, для повышения производительности;

  • расширения номенклатуры периферийных блоков.

Таким образом, симбиоз традиционного фон-неймановского архитектурного уровня RISC-V и не-фон-неймановской мультиклеточной микроархитектурой обеспечивает получение существенных конкурентных преимуществ процессоров RISC-V по сравнению с ARM и х86 при выходе на высокомаржинальные рынки (мобильные телефоны, планшеты, ПК, встроенные системы и супервычисления).

Комментарии (20)


  1. AlexeyK77
    27.11.2023 08:57
    +3

    Навеяло идеями VLIW. Практика показала, что если эффективность исполнения программы будет сильно зависеть от компилятора, то как процессор общего назначения не взлетит. Переписать все ПО тяжелее, чем сделать новый процессор.


    1. 1CHer
      27.11.2023 08:57

      А как же М1, 2, 3..?


      1. AlexeyK77
        27.11.2023 08:57
        +2

        а что там особенного, классический суперскаляр, правда с дополнительными блоками аппаратной акселерации насущных задач: видео, нейросети.


        1. select26
          27.11.2023 08:57

          Думаю вопрос был в том, что в случае с Мх "Переписать все ПО" никого не напугало и ваш тезис "как процессор общего назначения не взлетит" на практике не подтвердился


          1. AlexeyK77
            27.11.2023 08:57

            так его никто и не переписывал, а перекомилировал, архитектура то по сути таже. тут были эпичные баттлы на тему VLIW и почему с ним все не так просто, лучше почитать их.


    1. yatanai
      27.11.2023 08:57

      Самое грустно что классические подходы ещё себя не изжили. Помню читал про железо М1 и сложилось впечатление что они просто научились нормально мапить память и избавили кучу узких мест от копирования, в итоге +30% к скорости памяти из воздуха. И таких моментов в целом хватает


      1. select26
        27.11.2023 08:57
        +1

        Согласен. Иной раз думаю, что если бы ресурсы соизмеримые с разработкой нового железа бросили на разработку компиляторов, то выхлоп тоже был бы соизмеримый.
        Из того, что в голову первое приходит: цикл можно развернуть в линейный код, при условии что он помещается в кэш, и получить многократное ускорение за счёт prediction. Но, слишком много условий нужно учесть. В ряде случаев можно получить потерю производительности вместо ее прироста. Как говорится, море нюансов.


    1. SIISII
      27.11.2023 08:57

      Проблема не только в компиляторах, но и в том, что процессор выполняет программу не в сферическом вакууме, и всего не предусмотришь. Наиболее очевидная проблема -- конфликты при доступе к памяти. Если программе нужен доступ к области памяти, которой нет в кэше, приходится обращаться к реальной памяти, а это не только во много раз медленнее само по себе, но может натолкнуться на одновременный доступ со стороны других процессоров или периферии, использующей DMA, -- и, как следствие, выполнение операции доступа к памяти придётся задержать на довольно неопределённый срок. Если VLIW не может завершить выполнение текущего "командного слова" до тех пор, пока не будут выполнены все заданные операции, проц, очевидно, вынужден стоять и ждать завершения обращения к памяти. Классический суперскалярный проц с внеочередным выполнением в такой ситуации стоять не будет -- он продолжит выполнять команды, расположенные уже после ожидающей операции доступа к памяти, если между ними нет зависимости по данным.


    1. VSMC Автор
      27.11.2023 08:57

      Именно с этим фактором столкнулись, продвигая мультиклеточную архитектуру. Именно поэтому предложили идею взаимодействия с risc v.


  1. MANAB
    27.11.2023 08:57

    Может внедрение ECS паттерна может помочь? Это реально вопрос, я еще только пытаюсь в него въехать, не знаю еще, на сколько применим в корпоративной разработке.


    1. synputer
      27.11.2023 08:57

      ESC - это инструмент для программиста, а не для процессора. От него ничего не остается пока он пройдет все этапы трансляции в машинный код. Хотя, ход мыслей правильный. На любом уровне описания алгоритма, представление его в виде зависимости между данными более эффективно, чем в виде последовательности выполняемых операций.


  1. Sabirman
    27.11.2023 08:57

    У меня ноут 10-ти летней давности и процессор загружен в среднем на 5%. Т.е. грузят процессор совершенно определенные алгоритмы и именно под них и нужно оптимизировать процессор. Например, в arm есть специальные сопроцессоры для обработки видео.


    1. VSMC Автор
      27.11.2023 08:57

      Именно по такой логике система команд arm в конечном итоге получилась очень далекой от минималистичной - для работы с разными алгоритмами под разные задачи.

      Особенность же мультиклеточной архитектуры не в радикально новой системе команд, а в альтернативном подходе к выборке команд и промежуточных результатов, который реализует естественный параллелизм на аппаратном уровне.


  1. quarus
    27.11.2023 08:57
    +1

    Пока успех архитектуры RISC-V — это, в первую очередь, ее открытость.

    ...

    Открытость архитектуры важна для стартапов и небольших компаний. Для компаний, которые доминируют на этих рынках, важны другие характеристики.

    Мультиклеточная архитектура — принципиально новая, патентно-защищенная, не-фон-неймановская архитектура.

    Подобный путь должна будет пройти и архитектура RISC-V, чтобы выйти на эти рынки.

    ...мы забыли про симбиоз и строим только паразитарные модели и структуры. Грустно.


    1. VSMC Автор
      27.11.2023 08:57

      Как бы ни была хороша и открыта система команд risc v, её одной мало, чтобы разработать процессор. Нужна периферия под поставленную задачу. И тут уже не так всё просто с патентованием, в том числе системы команд, которая может расширяться за счет периферии.

      https://habr.com/ru/news/758762/


    1. synputer
      27.11.2023 08:57

      Вся центральная часть статьи - это описание симбиоза. Насчет грусти, да, очень грустно. особенно, когда внимательно почитаешь сайт компании SiFive и задашь себе пару вопросов (технический и маркетинговый).

      Во-первых, во что декодируют команды в процессорах этой компании, если сама по себе архитектура RISC имеет предельно простые команды. Понятна логика например декодирования CISC команд в команды типа RISC в суперскалярах х86. Но RISC во что? Ответа на этот вопрос нет. Пишут, как и в настоящей статье, что все фишки обеспечиваются микроархитектурой. На этом все.

      Во - вторых, компания выпускает хорошие процессоры, может быть даже лучшие из RISC-V. Но, почему-то не слышно ни о смартфонах с этими процессорами,ни о планшетах и т.д.. Первый суперскаляр они сделали в 2019. Прошло 4-года. Вопрос - чего не хватает в продвижении этих продуктов?


  1. DimErm
    27.11.2023 08:57

    Существующие реализации  RISC-V — это, как правило, микроконтроллеры. Например, как микропроцессор MIK32, созданный АО «Микрон».

    Очень ограниченный взгляд на ситуацию. Сама классификация risc-v решений показывает, насколько разнообразен сегмент уже имеющихся процессоров.

    Также довольно легко найти уже готовые процы и платы с ними под традиционную замену PC компьютеров. И здесь опережение арм назревает, рынок быстро наполнится альтернативными и более мощными системами


    1. VSMC Автор
      27.11.2023 08:57

      Немаловажным преимуществом arm здесь является унификация. Создавая разные ядра под разные задачи, они могут обеспечить какую-никакую преемственность периферии и системы команд.

      В то же время когда разные разработчики делают на основе risc v устройства под разные задачи - они очень вряд ли сохранят ту минималистичную систему команд и смогут обеспечить совместимость между своими процессорами.

      На данный момент количество смартфонов на arm гораздо больше смартфонов на risc v. Чтобы это изменилось, сама архитектура risc v должна будет претерпеть изменения.

      Случится ли это когда-нибудь и как это будет выглядеть - покажет время.


    1. synputer
      27.11.2023 08:57

      Не ограниченный, а реалистичный. Классификация - это протокол о намерениях, а не реальные сегменты, где уже используется RISC-V.

      Буду благодарен за ссылку, где можно поискать и купить мамину плату на традиционную замену в мой старенький PC компьютер . Искал, но не нашел.


  1. VaalKIA
    27.11.2023 08:57

    Вы хорошо рассказываете про автораспараллеливание комманд в рамках одного процесса, но современные реалии таковы, что компьютеры используются в мультипрограммном, а значит и в многопоточном режиме. Это означает, что одновременно исполняются программы, которые ничего друг о друге не знают, и не имеют общую кодовую базу. Это так же означает, что, например, на 4 ядерном процессоре нельзя одновременно запустить 4 функции, выполняющие один и тот же объём работ и, таким образом, ускорить, практически, без накладных расходов, программу в 4 раза. Нет, "соседняя", программа будет работать на тех же 4 ядрах, поэтому, один экземпляр функции будет выполняться на 1 ядре, второй на 0.1 ядре, а ещё два будут ждать освобождение ресурсов (соответственно, ждать окончания исполнения такого "пакета", что бы начать выполнять следующий - контрпродуктивно, потому что ожидание может затянуться на 10x и более, тогда как ускорение возможно только в 4x, далее идут накладные расходы на диспетчеризацию и загрузку ресурсов и всё это становится очень непростым делом), именно это очень сильно осложняет параллельное программирование, а не внеочередное исполнение потока комманд.

    Наскольо я знаю, в планах мультиклет, было выпустить 256 клеточный процессор, но через некоторое время, вы их изменили, на более реалистичный сколько-то ядер по 4 клетки. И тут, мы приходим к тому, что разделяя клетки на группы, вы расписываетесь в полной беспощности в работе с многопоточным ПО. Если бы было всё так хорошо с выполнением по готовности, то это выглядело бы как: 1 клетка на поток и ещё 200 клеток, мигрирующих по потокам, прибивающимися туда, где они требуются, но у вас будут ядра по 4 клетки и, соответственно, не более 4 клеток на поток (либо софтовое распределене ресурсов на уровне ОС), печалька.. :(