Comments 33
Хотя с другой стороны, если вы учились (допустим) на микрокалькуляторе МК-54 или (допустим) на компьютерах ДВК и Радио-86
Это же ваши ровесники, получается.
Спасибо за статью. А как вы видите будущее RISC-V? Вроде бы китайцы забабахали ноут на RISC-V, так что "универсальные машины разработчика" скоро должны появиться. Соответственно, есть шансы, что софт под Linux будет довольно хорошо работать на RISC-V (и быть соответственно оптимизирован).
Есть вообще ощущение, что RISC-V — закрывающая универсальная RISC архитектура? То есть, следующей, имеющий шансы на широкое распространение уже не будет, вернее это будет не RISC.
*** Это же ваши ровесники, получается ***
Ну дык я же не эйджист
*** А как вы видите будущее RISC-V ***
RISC-V уверенно занимает разные встроенные ниши - ядра для контроллеров дисков, housekeeping ядра в SoC итд. Он фактически находится в той же позиции, что MIPS 10 лет назад, за исключением того, что за RISC-V стоит движуха, а MIPS рассматривался как выдавливаемый ARM-ом и утрачивающий поддержку. Теперь такие компании как SiFive, Andes и другие могут отвоевать часть рынка у ARM. RISC-V также заместил позиции MIPS при преподвании микроархитектуры в университетах.
Линукс на RISC-V разумеется работает. Для существенного распостранения RISC-V на high-end рынках (мобильный, ноутбуки, суперкомпьютеры) нужно две вещи: 1) инвестировать в микроархитектуру(*) (продвинутые предсказатели переходов, load-store units с multiple pipes, продвинутые суперскаляры и векторные расширения 2) поддержка RISC-V крупными софтверными компаниями, в первую очередь Гуглом для андроида.
(*) Архитектура = система команд и формат видимых программисту регистров, а микроархитектура = аппаратное устройство конвейера и структура вычислительных блоков.
На рынке КНР, где действуют санкции против Huawei, которому не дают использовать Google Store, у RISC-V есть возможность win big, если китайцы наймут достаточно продвинутых специалистов по микроархитектуре, которые смогут переплюнуть топовые Cortex-A ядра на бенчмарках типа CoreMark.
"закрывающей универсальной RISC архитектурой" RISC-V имхо не будет. Дело в том, что в процессе развития электроники могут появиться изобретения (например трехмерные чипы с хитро устроенной памятью), под которые нужно будет по другому оптимизировать систему команд. По сути, RISC-революция с load-store архитектурным подходом произошла на фоне быстрого роста отношения скорости арифметических вычислений к скорости доступа к памяти. Из-за этого оказалось выгодным строить кэши и редуцировать сложные методы адресации, чтобы избавляться от зависимостей между инструкциями и делать спекулятивное выполнение в суперскалярных конвейерах.
Что-то такое же, но в другую сторону, может появиться и в будущем, из-за чего в RISC-V могут обнаружиться неудобные вещи. Примеры неудобных вещей в прошлом: сегментные регистры в x86, branch delay slots в MIPS и регистровые окна в SPARC.
UPD: я прочитал вас невнимательно. "это будет не RISC" - ну да, при таких фундаментальных изменениях как я описал, это запросто может быть не RISC. Но может и RISC, трудно сказать.
Что-то такое же, но в другую сторону, может появиться и в будущем, из-за чего в RISC-V могут обнаружиться неудобные вещи
Большинство из такого рода проблем вполне решаются дополнительными расширениями. Я вот сходу не могу придумать какой-то разумный пример, где это не поможет и потребуется реально новую архитектуру придумывать. Хотя в теории всё возможно, конечно.
Мне кажется, главная угроза RISC-V - это потенциальный риск получить очень фрагментированную архитектуру, где будет куча как-бы RISC-V, но между собой не совместимых.
решаются дополнительными расширениями.
и
это потенциальный риск получить очень фрагментированную архитектуру
вот!
Возможно есть решение сделать какой-то надъязык? Близкий к RISC-V байткод, из которого получалась бы заточенная под конкретный набор расширений оптимизированная программа? То есть, аналог AOT в Андроиде, но для вот этого конкретного семейства процессоров?
вот!
Вряд ли нас ожидает такое количество каких-то фундаментальных изменений, они происходят не так часто. Проблема фрагментации RISC-V в первую очередь проистекает от обширности текущих направлений для применения.
Возможно есть решение сделать какой-то надъязык? Близкий к RISC-V байткод
Так сама ISA RISC-V в каком-то смысле и является таким байт-кодом. Архитектурные команды можно будет потом преобразовывать в что-то более удобное внутри аппаратуры. Вопрос в том, что в будущем парадигма может настолько серьёзно измениться, что делать это в hw будет либо слишком накладно, либо невозможно. Разработанный байт код сейчас, даже очень абстрактный, потенциально обладает той же проблемой.
Вопрос в том, что в будущем парадигма может настолько серьёзно
измениться, что делать это в hw будет либо слишком накладно, либо
невозможно.
Ну есть же транспилеры. Будет просто ещё один компилятор из RISC-V в RISC-V. Фактически, при установке программы будете прогонять "оптимизатор под процессор системы". Но, насколько я понимаю, в настоящих скомпилированных программах вырезана значительная часть информации, которая может быть крайне полезной для такой перекомпиляции. Поэтому байт-код может быть удобнее.
Проблема фрагментации RISC-V в первую очередь проистекает от обширности текущих направлений для применения.
Можно раскрыть?
Поэтому байт-код может быть удобнее.
Удобнее всё это сделать в проце и не городить не нужный огород в софтварном стэке. Тем более если это ничего не даёт по сути
Можно раскрыть?
RISC-V претендует на то, чтобы стать общей архитектурой для широкого набора примений - микроконтроллеры, высокопроизводительные GP процессоры, мобильные процессоры, AI-процессоры и т.д. Везде выдвигаются разные требования и необходимы разные расширения. Например, где-то нужен мощный блок SIMD, где-то нет. Где-то нужны всякие криптографические расширения, где-то нет. Где-то есть поддержка только 32 бит, а где-то только 64 . И таких различий достаточно много. В итоге архитектура может существенно расползтись - это проблема.
Удобнее всё это сделать в проце и не городить не нужный огород в софтварном стэке. Тем более если это ничего не даёт по сути
Это поможет избежать комбинаторного взрыва поддержки расширений в скомпилированном тексте программы. То есть, вам не надо будет делать ветвлений в случае если у нас AVX512 есть или нет.
Конкретно проблема SIMD в Riscv V решена достаточно универсально ( даже слишком на мой взгляд). Если интересно - ознакомьтесь. Остальное - это очень абстрактно, нужны какие-то конкретные примеры, потому что я не уверен, что понимаю ваше предложение до конца. Я лишь могу сказать, что не вижу варианта внедрения какого-то байт кода, который реально был бы полезен по сумме плюсов и минусов.
Ну всё же risc-v задокументирован достаточно хорошо, чтобы получать несовместимости, следуя стандартам. Но вот если кто-то будет пилить свои нестандартные расширения -- несовместимости будут.
Есть ещё более тонкая проблема -- пусть даже несколько контор сделали несколько ядер со стандартными расширениями, но всё равно под каждое ядро будут свои способы оптимизации кода и что тут делать -- не очень понятно. У того же gcc например поддержано оптимизациями довольно ограниченное кол-во ядер у ARM, а код для старых ядер (например cortex A8) с каждым релизом gcc становится только хуже (медленне, то есть налицо деоптимизация). Что будет в случае 100500 разных risc-v ядер -- пока не очень ясно, но хорошо точно не будет.
Он фактически находится в той же позиции, что MIPS 10 лет назад, за
исключением того, что за RISC-V стоит движуха, а MIPS рассматривался как
выдавливаемый ARM-ом и утрачивающий поддержку.
RISC-V принципиально отличается от других Рисков только реализованной открытостью (вокруг него есть движуха и сообщество). Но ведь и открытости часто достаточно — тот же Linux взлетел именно из-за неё.
RISC-революция с load-store архитектурным подходом произошла на фоне
быстрого роста отношения скорости арифметических вычислений к скорости
доступа к памяти
Вот это я и имел ввиду, что стоимость перехода с одного API микропроцессоров на другой API микропроцессоров чудовищно велика. Поэтому только такие масштабные изменения смогут сместить RISC-V с его положения, коли он займёт место универсального набора инструкций. Кмк. Хотя нельзя загадывать, конечно.
А что может быть из серьёзного? Открытость есть. Другая элементная база, приводящая к совершенно другой микроархитектуре? И только. Ну ещё "весь мир в труху" :-(, но это столь же неконструктивное предположение, как и солипсизм.
Какой смысл вы вкладываете в слово "открытость" когда говорите о RISC-V (я знаю значение этого слова в нескольких контекстах и перед комментированием просто хочу удостовериться, что мы говорим об одном и том же).
Это интересный вопрос. Я имел в виду free software, то есть, коммунизацию и соответствующее снижение рисков. То есть, то, чем gcc отличается от Sun Studio: лицензия GPL со всеми вытекающими.
Так я и думал. У процессоров это другое. Я это говорю уверенно, потому что мне где-то полгода платили зарплату как MIPS Open Technical Lead, то есть за то, что я разъяснял людям значение слова Open.
Так вот. Главным отличием RISC-V от скажем ARM является так называемая архитектурная лицензия. Это другое, чем лицензия на ядра, которые могут быть не-open и с архитектурой RISC-V. Разберем сначала другие аспекты.
Читать документацию на архитектуру (API процессора) и для RISC-V, и для ARM, и для MIPS могут все - в этом смысле она Open, хотя на ранней стадии разработки для ARM она закрыта, а для RISC-V она относительно открыта, так как определяется комитетом из академии и представителей индустрии.
Движуха по использованию процессоров и поддержки их со стороны софтверного коммьюнити есть и у ARM, и у RISC-V - в этом смысле они обе Open (слово Open в этом значении использовалось в 1980-х для например шины у PC).
Код на верилоге и документация по микроархитектуре высокопроизводительных RISC-V ядер от SiFive и других коммерческих проектировщиков IP не является Open. Этот код лицензируется за суммы в сотни тысяч или пару миллионов долларов (текущий ценник я не знаю, но это порядок). То есть это не как у Линукса, это скорее как Sun Solaris до открытия его кода - API общий (POSIX), код ядра закрыт. В этом аспекте RISC-V от SiFive и ARM одинаковы.
И вот теперь архитектурная лицензия. Это лицензия на право сделать микроархитектурую реализацию (написать свой код процессора на верилоге) которая является совместимой по API (по бишь по архитектуре) с соотвественно ARM или RISC-V. Пример использования архитектурной лицензии - процессор M1 от Apple. В ранних Apple iPhone Apple лицензировал готовые ядра на верилоге от ARM, а потом купил у ARM архитектурную лицензию и стал разрабатывать ядра сам. Вот тут есть ключевое отличие - архитектурная лицензия от ARM стоит суммы порядка десятков миллионов долларов или выше (я не знаю точный ценник сейчас), а вот архитектурная лицензия от RISC-V стоит 0, ничего. Если процессор совместим с архитектурой RISC-V - продавайте на здоровье без отчислений роялти, хотя нужно согласовать с комитетом RISC-V.
Из пункта (4) следует важное отличие для исследовательских проектов в academia. Ранее любой студент, который строил собственное ARM или MIPS ядро, и при этом использовал инструкции свежее чем 17-летней давности (патенты в США истекают через 17 лет) технически нарушал текущие патенты на архитектуру ARM или MIPS. MIPS смотрел на это сквозь пальцы, но ARM иногда присылал письма от юристов "cease and desist" то есть "прекратите немедленно".
Кроме этого, если этот студент утверждал, что его процессор является "процессором с архитектурой ARM", то он тем самым нарушал еще и трейдмарку (про это есть отдельный закон) - даже если не нарушал патент, то есть даже если использовал только версию архитектуры 20-летней давности.
Так вот: RISC-V это убрал, то есть из нулевого ценника на архитектурную лицензию следует свобода процессоротворчества для academia без риска получить письма от юристов. Вот тут главная openess (хотя, еще раз подчеркиваю, коммерческие ядра у RISC-V продаются за значительные деньги с закрытым кодом, то есть они не как gcc
То есть, RISC-V можно перебить по открытости, создав, скажем RISC-6, который будет давать то же самое, что RISC-V, но ещё и будет предоставляться более-менее полная линейка лицензированных под условной GPL исходников на верилоге для FPGA/ASIC/чего-только-можно + все тесты + разные кодогенераторы компиляторов. Так?
Я имею ввиду, что RISC-6 будет своей отдельной, несовместимой архитектурой.
И спасибо за детальное разъяснение!
Да, можно, и если у этого risc-6 будут ядра которые победят по бенчмаркам coremark и другим коммерческие ядра от ARM , SiFive итд, то такая архитектура может даже выиграть на рынке, хотя и не сразу.
На самом деле даже перебивать не нужно, достаточно просто сделать конкурентоспособные открытые (с открытым верилогом в гитхабе) high-end ядра архитектуры RISC-V которые бы выиграли бенчмарки у SiFive, Arm итд. Вот это будет действительно как Линукс и gcc.
>выиграли бенчмарки у SiFive, Arm итд
Зачем их выигрывать? Половина производительности при открытом исходном коде хватит за глаза для микроконтроллеров, носимых устройств и ноутбуков. Остальное можно со временем наверстать и догнать high-end ядра.
Тут есть несколько проблем. Рынок микропроцессорных ядер делится на несколько крупных сегментов.
Открытые RISC-V ядра микропроцессорного класса уже достаточны по производительности, но для рынка микроконтроллеров помимо ядра нужен еще и набор периферии - то есть нужно делать набор открытой периферии.
Открытые RISC-V для встроенных систем типа контроллеров дисков уже тоже близки к практичности, например есть SweRV EH1.
Но вот с ядрами для мобильных телефонов и ноутбуков сложнее - если они остают от топовых ARM-ов вдвое, то они могут стать немаркетируемыми - то есть будут интересовать только энтузиастов. Я на эту тему слышал от маркетологов MIPS в свое время .
Можно упирать на безопасность. Когда у конкурента наспех залатанные спекулятивные дыры, проприетарный процессор и его сложная проприетарная софтовая обвязка, то на твоей стороне всё прозрачно (пусть и за счет падения производительности). Понятно, что еще нужно решить проблему со всей прочей обвязкой - сделать её полностью открытой.
На такое позиционирование найдётся массовый покупатель. Особенно в мире, когда на мобильном или ноуте у тебя финансы (банки, крипта и т.д.) и переход веба на Web Auth API.
А что в этом плане значат идея https://www.securitylab.ru/news/532586.php (Китайский проект сделать форк под названием RISC-X),
Куда в RISC-V можно санкциями ударить если хочется?
Ну кроме производства и запрета продавать лицензии SiFive и прочим.
Некуда же? Зачем тогда идея с RISC-X ?
*** Другая элементная база, приводящая к совершенно другой микроархитектуре? ***
Вы не путаете тут архитектуру и микроархитектуру? Я написал выше, что другая элементная база може привести не только к изменению микроархитектуры, устройства конвейера (это происходит с каждым новым ядром), но и к изменению архитектуры, системы команд (помимо примера с отношением скорости арифметики к скорости доступа к памяти можно ещё вспомнить и про прогресс от аккумуляторных архитектур к архитектурам с большим количеством видимых программисту регистров).
У вас в поле термин "архитектура" — дурацкий. Реально это тип API процессора или тип языка ассемблера.
Я не путаю микроархитектуру и API процессора, то есть архитектуру. В том контексте, который мы обсуждаем, то есть, развитие производства микроэлектронике, ведущее к "увеличению отношения скорости арифметических вычислений к скорости доступа к памяти" напрямую действует на микроархитектуру. А уже на архитектуру (API) действует опосредованно, поэтому и возможно иметь х86 вот сейчас, несмотря на то, что соотношения скоростей изменились принципиально.
То есть, зависимость там такая:
1. физические принципы определяют предельные параметры электрических схем,
2. предельные параметры эл. схем определяют принципы архитектуры электрической схемы компьютера (мат. плата, отдельный ЦП, отдельная память, встроенная или отдельная видеокарта, шины, связывающие их)
3. принципы архитектуры эл. схемы компьютера определяют микроархитектуру процессора (и, видимо, других частей компьютера)
4. и уже микроархитектура процессора, GPU, памяти, определяет интерфейсы => ассемблер => архитектуру процессора (RISC/CISC, что там ещё)
-------------------
Поэтому микроархитектура получается первичнее архитектуры ЦП. И она первой изменится, если мы перейдём, скажем, на графен. А вот изменится ли при переходе на графен архитектура ЦП (ассемблер) — это не факт, т.к. там есть некоторые "резервы адаптивности" (не знаю, как именно это назвать).
А в московском Samsung hw разрабатывают?
Очень полезно для анализа чужого кода.
Вот кстати, а какие требования промышленные ASICоделы в целом и Samsung в частности предъявляют к коду? Как управляют сложностью? Может быть какие-то метрики тулзами считают и дают по рукам за превышения? Вопросы навеяны такой книжкой.
Это очень обширный вопрос - про управление сложностью, в это входит и IP reuse, и методологии верификации, и автоматическая генерация кода для регистров и интерфейсов итд. Но метрики как везде - блок должен вписываться в бюджет тактовой частоты, количества D-триггеров, площади, статического и динамического (зависящего от количества переключений). Первые четыре метрики меряются во время синтеза (грубого, без floorplan , и более точного, после размещения). Последняя метрика требует более тонких методов - симуляции на уровне графа логических элементов после синтеза с помощью тулов типа Synopsys PrimeTime PX или Cadence Joules, или оценки с помощью Mentor Power Artist.
Но метрики как везде - блок должен вписываться в бюджет тактовой частоты, количества D-триггеров, площади, статического и динамического (зависящего от количества переключений).
Спасибо за развернутый ответ. Да, это ожидаемые и понятные метрики. Вопрос появился потому, что читал про ребяток, которые в качестве метрик в дополнение к этим ещё используют метрики сложности кода: т.е. стремятся минимизировать кол-во входных/выходных/внутренних состояний, кол-во конечных автоматов внутри одного модуля, кол-во строк кода и т.д. Их посыл в том, что это упрощает верификацию, уменьшает сложность и снижает кол-во ошибок. Не было понятно, стало ли это распространенной практикой в индустрии, или это больше их теоретические изыски в недрах Synopsys без особого продолжения.
В целях поддержания беседы, попробую привести свой вариант gearbox (пока без testbench):
Как подготовиться к собеседованию в Samsung Advanced Computing Lab