Найти тему
60,7K подписчиков

Философия архитектуры российского процессора Эльбрус. В чём его фишка?

21K прочитали

Ура! В связи с недавно прошедшим 8-м марта поздравляю всех женщин с этим весенним праздником! Если есть тут такие, конечно, среди моих читателей, чья область интересов лежит, в том числе, и в плоскости вычислительной техники :-)

Ну а теперь, собственно, про Эльбрус...

Многие, наверно, уже неоднократно слышали о том, что отличительной особенностью архитектуры процессоров Эльбрус является сверхдлинное машинное слово (VLIW). Но что это такое? Объясняю... на пальцах (С) )))

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

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

В Эльбрусах применён другой подход. В нём вся работа по распараллеливанию вынесена в компилятор, и процессору на вход подаются уже распараллеленные команды. Процессор не тратит энергию на аппаратное распараллеливание на лету, снижается выделение тепла.

Многие, наверно, уже неоднократно слышали о том, что отличительной особенностью архитектуры процессоров Эльбрус является сверхдлинное машинное слово (VLIW). Но что это такое? Объясняю...

Кроме всего прочего, распараллеливание компилятор может делать более качественно, чем это делает процессор на лету, потому что у него объективно больше информации о программе. Если процессор видит только небольшой кусочек кода, то компилятору доступен весь код приложения целиком.

Как любитель фотографии, я могу провести следующую аналогию. Любительский цифровой фотографирует и на лету сохраняет фото сразу в файл jpg. Все преобразования информации изображения он делает сам. Профессиональное же использование зеркалки подразумевает сохранение в сырой RAW-файл (исходник), и уже в комфортных условиях, на компьютере, обладая намного большими аппаратными и временнЫми ресурсами, RAW-конвертер преобразовывает сохранённую информацию об изображении в само конечное изображение. То есть, вся обработка того, что получено с матрицы фотоаппарата, вынесена из него наружу и обрабатывается во вне. Так же и с процессором, только последовательность будет обратная.

Философия архитектуры Эльбрус такая — всё, что можно сделать с кодом до того, как он поступит в процессор, имеет смысл сделать заранее. Этим самым повышается степень распараллеливания кода. Зачем нагружать процессор лишней работой, которую можно сделать при компиляции.

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

Почему конкуренты отказались от VLIW?

Если всё так перспективно, то почему этоuj не делает Intel? Ну, во-первых, он пытался это делать в серверном процессоре Itanium. Но в Itanium эта архитектура была сильно упрощена (IA-64). Процессор мог выполнять только 6 операций за такт, тогда как Эльбрус — до 25 операций, а сегодня и плюс 41 операции в векторном режиме.

Кроме того, для использования даже этих скромных возможностей, ПО для Itanium надо было оптимизировать. В неоптимизированном ПО производительность у первого варианта Itanium была ниже процессоров классической архитектуры в 8 раз. Это, конечно, отрицательно сказалось на его продажах. К

Компилятор для Itanium тоже был далёк от совершенства (у Эльбруса на текущий момент он намного более продвинут).

Itanium пережил несколько модернизаций, но в конце концов проект был заморожен. Разработчики в рамках архитектуры Itanium не смогли решить ряд технических проблем для полного раскрытия потенциала своей архитектуры, а на более значительные её изменения они не пошли. Сильно упираться в Itanium, давя им успешную на тот момент архитектуру x86, смысла не было, а навредить бизнесу могло.

Почему у нас нет другого выхода?

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

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

У нас риска потери рынка нет за неимением рынка, как такового. А это означает, что все те известные проблемы архитектуры Эльбрус так или иначе обречены на своё решение.

А вы как думаете, к какому году десктопные Эльбрус сравняются с наиболее популярными десктопными Intel? Я вот думаю, что в 2027-2028 годах уже станет всё не так однозначно :-)

Пишите свои мысли в комментариях, ставьте лайки, подписывайтесь на канал. Удачи!