За последние пару лет я написал довольно много статей про российский микропроцессор эльбрус и особенности его архитектуры. Основная мысль, которую я хотел донести, заключалась в том, что это единственная независимая от иностранных компаний архитектура, а значит, именно на неё нужно делать основную ставку.
Положительные моменты архитектуры следующие:
- В ядрах Эльбруса заведомо нет иностранных закладок, чего нельзя сказать про покупные ядра Байкала.
- На ядра Эльбруса нет иностранных патентов, а значит, у США меньше рычагов запретить иностранным компаниям производить построенные на них процессоры. Другое дело, что в самом процессоре Эльбрус есть некоторые запатентованные решения, и от них нужно избавляться. Кстати, недавнее допсоглашение на разработку процессора «Эльбрус-16С+» вместо «Эльбрус-16С», продлевающее разработку процессора аж на три года (до 12 декабря 2023-го), может быть связано с заменой лицензионных решений на свои с тем, чтобы беспрепятственно возобновить производство этих процессоров в Китае.
- На части задач архитектура позволяет повысить параллелизм выполнения операций путём загрузки большего количества АЛУ (арифметико-логических устройств) одновременно. При этом ответственность по одновременной загрузке АЛУ лежит исключительно на ПО (программном обеспечении), в частности, на компиляторе.
- Сама архитектура Эльбруса не связана никакими лицензиями с внешними игроками, и разработчик волен изменять её как угодно по собственному разумению и развивать в любом удобном для себя направлении. Вот об этом моменте мы и поговорим чуть позже.
Отрицательные моменты архитектуры тоже имеются. Оставим различные проблемы с кэшем, переключением контекста и т.п. Это всё можно так или иначе решить с той или иной степенью эффективности. Но вот то, что несколько десятков лет считалось преимуществом в наших реалиях, сегодня уже не выглядит таковым.
Я имею ввиду вынос работы по распараллеливанию операций из железа в компилятор. С одной стороны, при дефиците микроэлектронщиков и уровне производства, такое решение выглядит разумным. Программистов у нас всегда было много, и благодаря традиционно хорошей математической школе они были хорошими, чего нельзя было сказать про достижения аппаратного обеспечения.
С другой стороны, по факту мы видим, что разрабатываемый уже достаточно долгое время компилятор всё ещё далёк от совершенства. Кроме того, практика написания программ под этот процессор показывает, что не каждый программист сможет написать приемлемый код, который компилятор сможет эффективно распараллелить. Программист должен постоянно использовать определённый набор приёмов программирования, иначе компилятор выдаст крайне неэффективный код.
То есть, в то время, как весь мир решает проблему объективной сложности создания программных продуктов, что, в общем-то, правильно, мы с программированием Эльбруса движемся в обратном направлении, и это вызывает вопросы о верности выбранного пути.
Что делать?
Ни за что не отказываться от собственной архитектуры. Это аксиома. Какая бы ни была отечественная архитектура, она должна существовать и развиваться. Без разработки процессоров с собственными архитектурами не будет и полноценной самостоятельной отрасли. Самостоятельной, развивающей себя больше, чем конкурентов, а не как это было до сей поры с собственными разработками на базе процессоров x86.
Но вот, как мне кажется, стоило бы подумать о некоторых дополнениях в архитектуру. Например, об эффективной аппаратной предвыборке кода (hardware prefetcher) и предсказателе переходов (branch predictor).
Возможно, стоит дополнить VLIW-архитектуру аппаратной надстройкой с другой системой команд. Это может быть даже RISC-V, если она приемлемо ляжет по аппаратной составляющей своей архитектуры. В ином случае следует разработать свою архитектуру команд, которую было бы максимально просто наложить на существующую архитектуру АЛУ.
Тогда у программиста появился бы выбор — полагаться на свою квалификацию и возможности компилятора или писать в новой системе команд, из которой аппаратная предвыборка будет сама дёргать код и распихивать его по тем же АЛУ. Во втором случае аппаратная часть процессора, отвечающая за новую систему команд и её предвыборку будет автоматически отключаться и экономить энергию.
Да, в общих чертах это выглядит сложно в реализации. Сразу возникает масса архитектурных вопросов и причин, по которым это сделать невозможно. Так всегда бывает в самом начале работы, а потом у тех, кто ищет возможности, а не причины, всегда находятся те или иные пути решения любых затруднений.
А может, совсем отказаться от VLIW?
Может, но не хотелось бы лишаться его потенциальных возможностей, дающих преимущества на некоторых задачах. Я бы попробовал оставить широкое командное слово.
Ведь, по сути, похожая вещь происходит и в микропроцессорах Intel x86. Там инструкции x86 перекодируются в микрокоманды длиной более 100 бит (ссылка не доступна с российских IP, но можно воспользоваться средствами обхода), несущие много дополнительной информации, которые и выполняются. И да, это не RISC-команды, как это пытаются представить маркетологи Intel, заявляя, что современный x86 — это CISC/RISC-процессор.
То же самое можно было бы реализовать и для Эльбруса с той поправкой, что в качестве микрокоманд будут выступать VLIW-команды, а в качестве CISC-инструкций — инструкции какой-то наиболее подходящей для преобразования новой архитектуры. Ну и бонусом можно оставить доступ к «низкому командному уровню» — к VLIW-командам.
Заключение
Жду вашего авторитетного мнения в комментариях. Ставьте нравлики и подписывайтесь на мой канал. Удачи! :-)