Привет, постоянные и не очень читатели :)
Это снова я — с шестой (чиво?) статьёй из цикла про архитектуры, микроархитектуры, процессоры, наборы команд и всё такое. Что было раньше:
Part I: Скандальное разоблачение x86: ARM врывается с двух ног
Part II: Этой индустрии нужен новый герой: ARM врывается с двух ног
Part III: Китайский киднеппинг: похищение дочки
Part IV: RISC‑V — звезда родилась: x86 не у дел, ARM сломала две ноги
Part V: Смерть GPU/CPU на транзисторах — архитектура квантовых компьютеров
Part VI: У VLIW длиннее x86: Itanium в шаге от величества, Эльбрус — подержите моё пиво, тайны PS2 ← ВЫ ЗДЕСЬ
В прошлой статье я разобрал архитектуру квантовых компьютеров на примере каджитов (да, вы не ослышались), а также немного порассуждал на тему квантового превосходства.
В этой серии статье: возвращение к приземлённым транзисторным технологиям — разберём архитектуру VLIW (Very Long Instruction Word). Поговорим о предтечах, погрузимся в дух 1980-1990-х, узнаем, как Itanium стал Itanic’ом, как архитектура жила, живёт и будет жить. Ах да, будет про Эльбрус и даже PlayStation 2.
Осторожно, лонгрид! Термосы горячих и других согревающих напитков приветствуются.
Itanium - в шаге от величества
С учётом того, как развиваются технологии, какие продукты и компании есть на рынке, может показаться, что процессорные архитектуры — довольно скучная область, где всё устоялось. CISC (x86) и RISC (ARM, немного RISC-V) заняли свои места, попилили рынки, почти не соперничая друг с другом, разве что немного кусаются в сегменте ноутбуков. И никто ничего нового не ожидает
Но так было не всегда.
Дух эпохи: середина 1980-х — начало 1990-х
В мире всё “хорошо”: падение Берлинской стены, конец Холодной войны, Договор о Европейском союзе, технологический бум, американская поп-культура и кинематограф выдают будущую классику, вроде фильмов «Назад в будущее», «Терминатор» и «Криминальное чтиво», музыки Майкла Джексона и Нирваны. В нашем царстве шла Перестройка, следом распад СССР, а далее культурный взрыв: «Кино», «ДДТ», «Наутилус Помпилиус», фильмы «Брат» и многое другое.
Появился интернет — технологии соединяли мир, а культура распространялась с невероятной скоростью. Шёл активный переход к рыночным экономикам. Это была эпоха глобализации. В мире технологий и процессорных архитектур шли горячие дебаты между сторонниками CISC и RISC.
Технически концепция VLIW (Very Long Instruction Word или “очень длинное машинное слово”) появилась в 1970-х годах в академических кругах, но её популяризация началась именно в этой суматохе 1980-1990-х.
Теперь кратко о её сути (подробно препарировать будем дальше). VLIW — это архитектура, в которой несколько инструкций упаковываются в одно длинное машинное слово, выполняемое процессором за один такт. Все инструкции в таком пакете выполняются параллельно, что позволяет значительно повысить производительность в задачах с высоким уровнем параллелизма. При правильной реализации можно крайне эффективно использовать ресурсы процессора.
Уже по традиции отдам должное исследователю, известному в узких кругах (но не широкой публике) — Джошу Фишеру (Josh Fisher) из Йельского университета.
Пионер в VLIW-архитектурах, известен своими работами в области параллельной обработки инструкций и оптимизации производительности процессоров, использующих VLIW. Участвовал в разработке и популяризации подходов к использованию VLIW в высокопроизводительных вычислениях; работал над проблемами оптимизации компиляции.
Подробнее о Фишере
В 2003 году Компьютерное общество IEEE и Ассоциацией вычислительной техники присудила ему премию Экерта-Мокли в знак признания 25-летнего вклада в параллелизм на уровне команд, новаторской работы в области архитектур VLIW и разработки метода компиляции Trace Scheduling.
Первая коммерческая реализация VLIW случилась в 1987 году — это были процессоры TRACE от компании Multiflow Computer, которую осн��вал Фишер. TRACE могли исполнять до 28 операций за один такт, но эти системы оказались очень сложными и дорогими из-за нишевости (малый тираж).
Итак, VLIW — это не просто очередная архитектура / микроархитектура / ISA (Instruction Set Architecture), это концепция, которая могла полностью перевернуть мир вычислений. Но пока не сделала этого. В процессоростроении есть десятки архитектур, которые не захватывают новостные заголовки и не завоёвывают рынки. Обычно это узкоспециализированные технологии, которые не стали мейнстримом, но повлияли на индустрию — изменили её, отклонили вектор, если угодно.
Но как я уже говорил в других статьях, одной лишь отличной технологии недостаточно, чтобы заработать все деньги мира — и примеров тьма: продвинутый формат полудюймовых видеокассет (12,7 мм) Betamax от Sony проиграл простому VHS от JVC (технология должна быть не просто лучше, но доступнее, с экосистемой и соответствовать запросам рынка).
Windows Phone, которая запоздала с выходом, попала в слишком конкурентную среду и получила плохую поддержку разработчиков (экосистема оказалась важнее технологии).
В контексте VLIW логично упомянуть другую провальную технологию — процессоры Itanium (саркастически прозванные Itanic) на архитектуре IA-64 (Intel Itanium architecture).
Как затонул Itanic — EPIC fail
Архитектура IA-64 основана на концепции VLIW с модификацией EPIC (explicitly parallel instruction computing), то есть в основе лежат вычисления с явным параллелизмом машинных команд — это когда компилятор решает, какие команды процессору выполнять параллельно. Напомню, что в классических суперскалярных архитектурах (x86, ARM) процессор самостоятельно управляет зависимостями между командами во время выполнения — это требует сложной аппаратной логики, из-за которой растёт энергопотребление и усложняется дальнейшее масштабирование.
Если простыми словами, то основная идея EPIC — переложить определение параллелизма с процессора на компилятор. Именно программа должна сообщать процессору, какие части кода могут выполняться одновременно (параллельно). Теоретически это должно было подарить нам высокую производительность, но на практике компиляторы не так эффективно справлялись с анализом сложных зависимостей в реальных приложениях. Да и круг задач ограничен.
Дело вот в чём: компилятор не всегда может гарантировать, что процессор будет получать непрерывный поток команд для обработки. Поэтому процессоры на базе EPIC тоже сталкиваются с проблемами ветвлений (переходов). EPIC решает эту проблему с помощью механизма предикативного исполнения на предикатных регистрах.
Ремарка №1 (Осторожно, сложная техническая информация!)
В процессорах Itanium очень развитая система регистров (регистровый файл). Их много и устроены они довольно сложно.
Целочисленные регистры (General Registers, GR): 128 64-битных регистров. Используются для хранения логических, скалярных и векторных целочисленных данных.
Вещественные регистры (Floating-Point Registers, FR): 128 82-битных регистров. Используются для хранения вещественных данных. Каждый регистр хранит одно 82-битное вещественное число или два 32-битных вещественных числа.
Предикатные регистры (Predicate Registers, PR): 64 1-битных регистра. Используются для хранения результатов операций сравнения.
Регистры ветвлений (Branch Registers, BR): 8 64-битных регистров. Используются для хранения адресов перехода и возврата из подпрограмм.
Указатель команды (Instruction Pointer, IP): 1 64 битный регистр. Содержит адрес текущей исполняемой связки инструкций.
Прикладные регистры (Application Registers, AR): 128 64-битных регистров. Используются как регистры данных и управления для специальных целей. Некоторые из них: itc — счетчик тактов (Interval Time Counter), lc — счетчик цикла (Loop Counter), ec — счетчик эпилога (Epilog Counter).
Ремарка №2 (Осторожно, сложная техническая информация!)
Архитектура IA-64 в процессорах Itanium использует эффективные предикатные инструкции.
Предикаты — это флаги (бинарные условия), которые говорят, нужно ли выполнить конкретную инструкцию или нет. Они хранятся в специальных предикатных однобитных регистрах (64 штуки).
Один из этих регистров должен всегда иметь значение «истина», чтобы выполнить обычные инструкции, как если бы у них не было предикатов.
Зачем это нужно? Главная цель — оптимизация работы процессора. В IA-64 используется программный конвейер, который позволяет ускорить выполнение инструкций, так как процессор может заранее подготавливать и выполнять инструкции, даже если они пока не должны быть выполнены, исходя из условий.
Предикаты помогают упростить код и избежать механизма предсказания переходов. Вместо того чтобы писать отдельные блоки для каждого условия (например, для начала и конца функций), можно просто использовать предикаты для выполнения инструкций в зависимости от текущих условий. Это помогает избежать излишней сложности в коде и ускоряет его выполнение.
В результате процессор работает быстрее, а разработчикам проще писать более эффективный и компактный код.
Ремарка №3 (Осторожно, сложная техническая информация!)
В Itanium есть аппаратный блок управления регистрами Register Stack Engine (RSE) — динамический механизм, который управляет целочисленными регистрами и позволяет автоматически выделять и освобождать ��егистры для параметров функций и локальных переменных, минимизируя обращения к памяти.
В Itanium целочисленные регистры с плавающей запятой можно разделить на 2 группы и 3 подгруппы:
Static registers (32 регистра) — глобальные регистры, которые всегда доступны и сохраняют своё значение между вызовами функций.
Rotating registers (96 регистров) — регистры с кольцевым (циклическим) доступом. Используются для передачи аргументов между функциями и хранения локальных данных.
Они разделяются на:
Input — для получения аргументов от вызывающей функции.
Local — для локальных переменных текущей функции.
Output — для передачи аргументов в вызываемую функцию.
Вот что интересно — в зависимости от глубины вложенности вызовов функция могла динамически назначать разные наборы регистров из этих 96 для input, local и output. Если глубина вызова функций превышает количество доступных регистров, старые данные выгружаются в память (spill), а при возврате — загружаются обратно (fill). Этот процесс полностью автоматизирован и управляется на аппаратном уровне.
Итак, вернёмся к нашим предикатным регистрам в EPIC. Вместо того чтобы выполнять только 1 вариант инструкций, процессор одновременно обрабатывает несколько ветвей. Как только становится известно, какой из вариантов правильный, выполнение другой ветви прекращается.
Например, если результат операции A определяет, нужно ли выполнить B или E, процессор отправляет в конвейер команды A, B, C, D, E, F и G одновременно. Когда результат A готов, выясняется, что нужно продолжить с E. В этот момент выполнение B, C и D прерывается, а результаты E, F и G остаются в обработке. Если бы нужной оказалась цепочка B, C, D, процессор продолжал бы их выполнение без потери времени. Так EPIC экономит время, устраняя проблемы с ошибочным предсказанием ветвления. Те же процессоры, например на x86, используют предсказание ветвлений. Если предсказать не получилось, он сбрасывает конвейер и начинает выполнение с правильной ветви, что приводит к значительным временным потерям.
Иногда выполнение инструкций невозможно, так как процессору не хватает нужных данных — он вынужден запрашивать их из кэша, оперативной или постоянной памяти.
Чтобы сократить время ожидания, архитектура EPIC использует механизм спекуляции — компилятор заранее подсказывает процессору, какие данные могут понадобиться, и процессор кэширует их. Это позволяет минимизировать задержки при доступе к памяти, но есть и минусы: если за это время ситуация изменится, процессору придётся повторно проверять данные перед их использованием, чтобы избежать ошибок. В x86 спекуляция выполняется аппаратно: процессор сам предсказывает, какие данные понадобятся, и загружает их — механизм сложный и энергозатратный.
Вот ещё одна важная особенность EPIC: компилятор готовит наборы длинных инструкций, которые уже оптимизированы для параллельного выполнения. Он проверяет, какие команды могут выполняться одновременно, не мешая друг другу, и добавляет в инструкции информацию о зависимостях между наборами. В этих наборах также могут быть дополнительные команды, связанные с механизмами спекуляции. Такой п��дход кардинально отличается от архитектуры x86, где для анализа инструкций, управления зависимостями и предсказания ветвлений используют сложные аппаратные модули.
Вот такое противостояние ПО и железа — компилятора и аппаратной части.
Ниже можете изучить Intel Itanium (Merced). По современным меркам процессор выглядит странно — по сути это мезонинная плата с 418-контактным микропроцессорным разъёмом (PAC418). Сам кристалл распаян на плате внутри этого гробика.
Немного фото процессора Intel Itanium Merced
Первое поколение Itanium (Merced) выпустили на рынок летом 2001 года с ценой до $4000. Это были 180-нанометровые чипы с 25 миллионами транзисторов, TDP 116 и 130 Вт, частотами ядер 733 и 800 МГц. Вышли они после 10 лет разработки, но с запозданием, так как изначально планировались на 1997 год.
Название модели | Тактовая частота | Кэш | Скорость системной шины (FSB) | Ядра | Потоков на ядро | Вольтаж | TDP (Вт) | Сокет | |
L2 | L3 | ||||||||
Itanium 733 | 733 MHz | 96 KB | 2 МБ | 133 MHz | 1 | 1 | 1.25–1.6 V | 116 | PAC418 |
Itanium 733 | 733 MHz | 96 KB | 4 МБ | 133 MHz | 1 | 1 | 1.25–1.6 V | 130 | PAC418 |
Itanium 800 | 800 MHz | 96 KB | 2 МБ | 133 MHz | 1 | 1 | 1.25–1.6 V | 116 | PAC418 |
Itanium 800 | 800 MHz | 96 KB | 4 МБ | 133 MHz | 1 | 1 | 1.25–1.6 V | 130 | PAC418 |
Из-за этого процессоры Itanium первого поколения сильно отставали от современников на RISC и CISC, в том числе из-за неэффективной подсистемы памяти, слабых компиляторов и плохой эмуляции x86. Даже Pentium 4 Willamette, который вышел в ноябре 2000 года, содержал 42 миллиона транзисторов с тактовой частотой 1,4 и 1,5 ГГц (при том, что это был временный продукт для быстрого ответа на Thunderbird AMD Athlon, у которого был высокий TDP в 75 Вт, но это совсем другая история). Продажи Itanium Merced были скромными — несколько тысяч единиц.
Но не смотря на сомнительный старт, Intel и HP (заварили эту кашу вместе) позиционировали чипы Itanium как будущее для серверов — они должны были ознаменовать переход на 64-битные вычисления (такой вот повод нашли) и заменить вездесущую x86.
Вендоры обещали, что ко второму поколению McKinley всё станет сильно лучше. В целом так и вышло — во второй итерации процессоры Itanium стали конкурентоспособными по производительности на Ватт. Поддержка архитектуры IA-64 и программного обеспечения для неё постепенно улучшались, а это увеличило продажи.
Были мнения и настроения, что Itanium сможет доминировать на рынке (для начала серверном), но всё что-то пошло не так: AMD, как мы помним, показали свои Opteron на архитектуре x86-64; Itanium же стоили дорого, потребляли очень много электроэнергии, грелись и требовали мощного охлаждения, эмуляция x86 была ужасной (настолько, что её наличие — скорее недостаток, а подобные статьи тому свидетель), да и рынок в целом не был готов к переходу на VLIW-архитектуру. Itanium по продажам не смогла обогнать даже Power ISA и SPARC, а вы, вероятно, о них и не слышали.
В результате Itanium стал нишевым продуктом (корпоративный сегмент высокопроизводительных серверов) вплоть до своей кончины, а x86 продолжил доминировать.
Ничего удивительного, что технические проблемы, слабая экосистема и несовместимость с актуальными технологиями отпугивают покупателей. Но вот что интересно — агония продлилась аж до июля 2021 года, а поставки закончились на четырёхядерных и восьмиядерных процессорах Itanium 9700 Kittson.
Я мог бы подробно расписать историю Itanium с погружением в IA-64, в тонкости архитектуры, но эта статья всё же про VLIW. Однако история с Itanium важна и занимает заметную часть статьи, чтобы показать жизнеспособность концепции очень длинного машинного слова, что технология сама по себе хороша и может конкурировать с x86 и ARM. Но не все дыры и проблемы можно заткнуть большими деньгами и сильными брендами, вроде Intel и HP.
Простой мысленный эксперимент: меняем местами VLIW и x86 на восходе последней. Что получим? Мир, где VLIW собрал крепкий легаси код и оптимизацию, поддержку нескольких сильных вендоров и сторонних разработчиков, работает нативно со всем актуальным и востребованным софтом (корпоративным и, вероятно, консьюмерским), а также другие прелести первопроходцев. И неизвестно, в каком положении были бы x86 и ARM.
Если моя история про Itanium вас заинтересовала — пишите в комментарии. Увижу интерес — сделаю лонгрид в лучшем виде — всё как вы любите :)
Ну а пока нам предстоит обсудить ещё много интересного про VLIW: какие есть решения, кроме Itanium (я знаю, что вы знаете :D); что такое этот ваш VLIW, и почему (а главное, всё таки что) у него длиннее?
Выезжаем с полосы для разгона на магистраль, друзья.
Почему у VLIW длиннее: в начале было слово - очень длинное машинное слово
В основе VLIW лежит идея очень длинного машинного слова — пакет или связка (bundle) коротких инструкций, которые процессор выполняет параллельно за один такт. Длинное машинное слово может включать инструкции для арифметического блока (сложение или умножение), загрузки данных из памяти и управления потоком выполнения (переходы, вызовы функций). Все эти операции выполняются одновременно, чтобы функциональные блоки процессора почти не простаивали.
Архитектура VLIW опирается на важный принцип — перенос ответственности за выявление параллелизма на компилятор. Вместо того чтобы процессор динамически анализировал зависимости команд (как в суперскалярных ЦПУ), это делает компилятор на этапе компиляции. Он определяет независимые инструкции, группирует их в пакеты и генерирует длинные машинные слова для исполнения.
Чтобы такой подход работал, у процессора на VLIW как правило есть аппаратные функциональные блоки: ALU (арифметико-логические устройства), FPU (блоки обработки чисел с плавающей запятой) и специализированные ядра (например, для обработки мультимедиа или нейронных задач). Каждый из этих блоков может работать независимо, что позволяет достичь высочайшего уровня параллелизма.
Всё это замечательно и красиво на бумаге: VLIW позволяет упростить дизайн (конструкцию) процессоров, снизить энергопотребление за счёт исключения анализа зависимостей в реальном времени, повысить тактовые частоты (процессор ведь освободился от лишних задач). В жизни же Intel Itanium работал на более низких частотах, чем конкуренты на x86 — всё из-за сложной микроархитектуры и высокой длины конвейера.
Ну и главное — сложный компилятор стал криптонитом VLIW. В реальных приложениях, где код сложен и динамичен, компиляторы просто не могли оптимизировать и распараллелить команды, чтобы максимально раскрыть потенциал VLIW.
И позвольте мне кинуть небольшой астероид в огород разработчиков (или большого “джастбизнеса”, который принимает решения). Это ИМХО автора — мысли вслух: вместо качественного кода, вдумчивого и оптимизированного, разработчики выбрали стратегию латать течи производительностью железа. Например, в x86 добавляли всё больше транзисторов для предсказания ветвлений, а на примере RTX 5000 видно, что железо больше не прибавляет по 30-50% производительности от поколения к поколению, и путь этот тупиковый. Оптимизация кода/компиляторов — вот куда всё и придёт, а не к гигантским чиплетам, многоядрам и многогерцам.
Ладно, пора переходить к проблемами, с которыми VLIW столкнулась в реальной жизни.
Проблемы VLIW: почему архитектура не стала мейнстримом?
Первое - жёсткая зависимость от компилятора
Ошибки компиляции или недостаточная оптимизация приводят к провалам производительности VLIW. Архитектура устроена так, что показывает достойные результаты в строго контролируемых средах, где выполнение команд можно точно предсказать и заранее оптимизировать
Здесь я вижу фундаментальную проблему всей концепции длинного машинного слова — жёсткую привязку к конкретному набору инструкции. VLIW-подобные архитектуры используют фиксированную длину командного слова, например, 64 бита или 128 бит, куда упаковываются несколько инструкций. Если одна из инструкций не используется (например, нет независимой задачи для её функционального блока), этот слот остаётся пустым, что приводит к неэффективному использованию вычислительных ресурсов (проблема общая, но не абсолютная, в том же Эльбрусе её минимизировали, но об этом дальше).
В отличие от x86, где динамическое планирование команд позволяет заполнять простои на лету, в VLIW конвейер жёстко связан с решениями компилятора, а значит, часть вычислительных блоков может и будет простаивать.
Второе - совместимость и экосистема
Отвратительную совместимость с x86 приложениями я уже упомянул выше на примере Itanium. Но что если это проблема Intel и HP, а не VLIW? Что если опытные инженеры, которые разбираются в тонкостях обеих архитектур, смогли бы создать эффективный динамический двоичный транслятор по типу Rosetta от Apple?
Ремарка! Даже теоретически создать что-то на уровне Rosetta для VLIW-архитектуры очень сложно, так как x86 содержит массу зависимостей и самоуправляемых механизмов, которые в VLIW просто отсутствуют.
В этом контексте упомяну Эльбрус (к нему мы ещё вернёмся) — российскую архитектуру и одноименные ЦПУ на базе VLIW, которая использует технологию динамической двоичной трансляции, встроенную в процессор. В Эльбрусах программный слой в реальном времени конвертирует x86-инструкции в инструкции VLIW, следом переведённые фрагменты кода кэшируются, чтобы ускорить их повторное выполнение. И как ни странно процессоры Эльбрус довольно стабильно и эффективно работают с x86-приложениями, ОС и BIOS, даже сложными. Относительно Itanium — лёд и пламя, но Эльбрус, разумеется, не может конкурировать с нативными x86-процессорами по скорости выполнения кода.
У проблемы совместимости в мире VLIW есть и другая сторона — внутренняя. По сути нет единого стандарта. Софт, написанный для конкретного VLIW-процессора, может быть несовместим с другим из-за различий в длине командного слова, реализации компилятора и набора инструкций. То есть ПО сложно перенести даже внутри экосистемы VLIW. Речь не про обратную совместимость, а скорее про разные реализации VLIW: Itanium и Эльбрус не могут работать с нативным софтом друг друга. В мире x86, как вы знаете, AMD и Intel отлично работают со всем x86-софтом благодаря совместимости на уровне инструкций (кроме некоторых проприетарных приложений, где может быть урезан функционал).
Так что VLIW сталкивается сразу с двумя недостатками: сложностью взаимодействия с внешними архитектурами и отсутствием единого стандарта внутри. Крепкую экосистему на такой базе построить непросто, особенно на фоне x86, которая годами наращивает легаси хвост и сохраняет обратную совместимость, а пользователи и разработчики получают стабильную платформу.
Ранние представители VLIW: Multiflow TRACE и Intel i860
Первая серьёзная попытка создать VLIW-процессор принадлежит компании Multiflow Computer, Inc. (её основала группа инженеров, один из них — тот самый Джош Фишер).
Multiflow в мае 1987 года показала TRACE 7/200 и TRACE 14/200 — мини-суперкомпьютеры на архитектуре VLIW, способные выполнять 7 (4 целочисленные/операции с памятью + 2 операции с плавающей запятой и 1 переход (branch)) и 14 операций соответственно за каждый такт. Чуть позже появилась и более мощная версия 28/ (можно сказать, что это 28 ядер). Теоретическая производительность с достаточным уровнем ILP впечатляла. Компилятор Trace Scheduling Compiler анализировал код и группировал независимые инструкции в длинные машинные слова.
Но в итоге устройства оказались слишком дорогими и нишевыми (ЦА — исследователи и научные организации), а сложность программирования и конкуренция не оставили шансов. Компанию не спасли даже инвестиции DARPA (Агентство перспективных исследовательских проектов Министерства обороны США) — уже к 1990 году её технологии и патенты выкупила Hewlett-Packard, туда же перешли и инженеры (ага, Itanium не с 0 разработали).
В 1989 году на свет божий выбрался Intel i860 — пожалуй, первый коммерческий VLIW-процессор, который Intel пыталась позиционировала как революционное решение с высокой производительностью в операциях с плавающей запятой: 3D-графика, научные вычисления и обработка сигналов. У разработчиков было другое мнение — они столкнулись с невероятно сложным процессом программирования. Отсутствие динамического планирования команд требовало идеально оптимизированного кода, а компиляторы того времени просто не могли справиться с этой задачей. В результате i860 не нашёл массового применения, но частично повлиял на развитие SIMD-инструкций (Single Instruction, Multiple Data) в последующих поколениях x86. Технологии MMX и SSE во многом обязаны идеям, заложенным в i860.
Затем в игру вступил Itanium, самый амбициозный (и, возможно, самый громкий) VLIW-проект в истории. Про него я уже достаточно рассказал — архитектура обещала революцию, но вместо этого пошла на дно.
VLIW — оно живое: от DSP и PlayStation 2 до ноутбуков для подводных лодок на Эльбрусе
С массовым рынком у архитектуры не задалось, но полностью VLIW не исчезла. Архитектуру по прежнему используют там, где компилятор заранее знает, что делать с кодом — в нишах, где потоки данных можно легко распараллелить.
Digital Signal Processor (DSP) или цифровые процессоры обработки сигналов (ЦПОС) — музыка, видео и телеком
Одним из первых коммерчески успешных примеров VLIW стали Texas Instruments TMS320C6x — семейство производительных DSP-процессоров, созданных специально для работы с численно интенсивными вычислениями. Главное преимущество DSP в том, что они гибкие и экономичные. В отличие от жёстко зашитых аналоговых схем, DSP могут перепрограммироваться под разные задачи, а их работа меньше зависит от температуры и других внешних факторов.
Классическая схема работы DSP выглядит так:
Аналого-цифровой преобразователь (ADC) превращает внешний с��гнал (например, голос) в цифровую форму.
Сигнальный процессор (DSP) выполняет обработку — фильтрацию, сжатие, улучшение качества.
Цифро-аналоговый преобразователь (DAC) возвращает сигнал в аналоговую форму (например, звук в колонках).
Почему VLIW так хорошо подходит для DSP? Всё просто: в задачах реального времени важно, чтобы процессор гарантированно справлялся с обработкой за строго заданное время. VLIW-архитектура позволяет выполнять максимум операций за один такт, а это высокая энергоэффективность и предсказуемость работы.
Texas Instruments, Qualcomm и другие компании давно используют VLIW в сигнальных процессорах. Например, Qualcomm Hexagon — VLIW-архитектура, лежащая в основе DSP в мобильных процессорах Snapdragon. Она помогает обрабатывать звук, изображения, ускорять ИИ-вычисления. VLIW здесь работает, потому что задачи предсказуемы, а компиляторы уже знают, как распараллелить код.
PlayStation 2 и её тайна
Если у вас в детстве/молодости/сейчас есть Sony PlayStation 2, то VLIW-архитектура ближе, чем кажется. Консоль основана на процессоре Emotion Engine (EE) — это система на кристалле с VLIW-блоками, разработанная Toshiba и лицензируемый Sony.
Так как EE — это SoC, то в нём есть несколько компонентов и блоков:
Основной 64-битный ЦПУ (Архитектура MIPS R5900, набор команд MIPS III и MIPS IV с расширениями SIMD);
Engines (специализированные блоки): нам в этой статье интересны векторные сопроцессоры (VPU0 и VPU1) для обработки графики и физики;
Модуль DMA (Direct Memory Access) для быстрого обмена данными между компонентами;
Модуль управления памятью (Memory Interface);
Кэш: L1 на 16 КБ для инструкций и на 8 КБ для данных + Scratchpad RAM (или S-RAM, или Fast RAM) на 16 КБ — по сути расширенный кэш который позволял обойти задержки RDRAM с узкой шиной на 16 бит.
По сути EE — это проприетарный чип на MIPS R5900, в котором используется комбинация из CPU и специализированных блоков для отдельных блоков. Так как это чип для консоли, его основная задача — работа с 3D-моделированием.
Для этого у Emotion Engine есть два идентичных (микроархитектурно) векторных блока — Vector Units (VU). Оба блока, VU0 и VU1, основаны на архитектуре VLIW, а значит могут выполнять несколько операций за один такт. Скажу сразу, там всё непросто, а разобраться в этом деле мне помогла статья с сайта arstechnica.com (её автору, Джону Стоуксу, низкий поклон).
Дальше будет сложная техническая информация. Предупреждён — значит чаем с бутербродом вооружен.
Итак, VU0 — это 128-битный сопроцессор для ядра MIPS III, объединяющий технологии SIMD и VLIW. Для программиста VU0 выглядит как дополнительный логический конвейер, который функционирует параллельно с целочисленными ALU. Команды, запускающие VU0, — это 32-битные инструкции MIPS COP, перемежающиеся с целочисленными операциями, командами FPU и переходами.
Во время рендеринга центральный процессор часто использует отдельный поток для управления VU0. Он передаёт данные с плавающей запятой по выделенной шине в виде 128-битных блоков (w, x, y, z). Затем VIF (блок интерфейса векторных данных) разбивает их на четыре 32-битных слова для обработки FMAC (блоком умножения-сложения с плавающей запятой).
VU0 использует собственный набор из 32 128-битных FPR (регистров с плавающей запятой). Каждый такой регистр может хранить четыре 32-битных числа с одинарной точностью. Кроме того, VU0 включает 16 16-битных целочисленных регистров для выполнения целочисленных операций.
VU1 — это полностью автономный процессор SIMD/VLIW, который наследует все архитектурные особенности VU0, но при этом добавляет новые функции. Эти дополнения связаны с его ролью геометрического процессора для Graphics Synthesizer (GS), что позволяет ему теснее интегрироваться с GS. Главное новшество — дополнительный функциональный блок, называемый элементарным функциональным блоком (EFU). EFU состоит из одного FMAC (блока умножения-сложения с плавающей запятой) и одного FDIV (блока деления с плавающей запятой), аналогично FPU основного процессора. EFU берёт на себя выполнение простейших вычислений, необходимых для расчёта геометрии.
Ещё одно ключевое отличие VU1 от VU0 — объём памяти. VU1 располагает 16 КБ памяти для данных и 16 КБ памяти для инструкций, в то время как у VU0 только по 8 КБ каждого типа. Увеличенный объём памяти для данных критически важен, поскольку VU1, как геометрический процессор, обрабатывает значительно больше данных, чем VU0.
Кроме того, VU1 поддерживает несколько способов передачи данных в GIF (и далее в GS). Как и VU0, он может отправлять списки отображения в GIF через основную 128-битную шину. Также VIF VU1 способен передавать данные напрямую в GIF. Наконец, существует прямая связь между 16-килобайтной памятью данных VU1 и GIF. Это позволяет VU1 работать со списком отображения в своей памяти данных, а DMAC (контроллер прямого доступа к памяти) — передавать результаты напрямую в GIF.
И пару слов про SIMD/VLIW — что это за зверь такой. Процессор Emotion Engine одновременно выполняет несколько инструкций (VLIW), причём часть из них работает в режиме параллельной обработки данных (SIMD).
В контексте наших векторных блоков VU1 и VU0 это означает, что процессор выполняет длинные 64-битные инструкции, которые делятся на две 32-битные части. Эти части выполняются параллельно двумя исполнительными блоками: верхним и нижним. Верхний блок работает в режиме SIMD, то есть выполняет одну инструкцию над несколькими данными одновременно (например, 4 операции сложения или умножения с плавающей запятой за раз). Нижний блок не использует SIMD, а выполняет более специализированные задачи, такие как деление, загрузка/сохранение данных, переходы и другие операции.
Вот такие дела :)
В итоге процессор Emotion Engine получился отличным, но сложным из-за специализированных VLIW и других блоков. Графический конвейер (назвать классическим GPU это нельзя) в виде Graphics Synthesizer был крайне странным.
Разработчикам приходилось жёстко оптимизировать код, чтобы задействовать весь потенциал Emotion Engine. Поэтому ранние игры для PS2 выглядели не особо лучше, чем на первой PlayStation — разработчики просто не успели освоить сложную архитектуру.
Но студии, вроде Naughty Dog и Santa Monica, спустя годы научились выжимать максимум из EE. Те же разработчики из Naughty Dog использовали ассемблер для VU. Поэтому поздние игры — God of War 2, MGS3, Gran Turismo 4, Black, Shadow of the Colossus — выглядели потрясающе по меркам своего времени.
Transmeta Crusoe — энергоНЕэффективные
В 2000-х компания Transmeta дважды запрещённая в России организация попробовала пойти по другому пути, создав процессоры Crusoe и Efficeon, использовавшие VLIW с эффективной динамической трансляцией x86-кода. То есть, по задумке процессоры должны были работать с Windows и стандартными приложениями, но расходовать в разы меньше энергии.
Были даже консьюмерские устройства: нетбук Sharp Actius MP30, ноутбук iRU Stilo 1715.
Как и Itanium, решения Transmeta столкнулись с проблемами: производительность при эмуляции x86-инструкций была ниже, чем у классических x86-процессоров, а софт требовал дополнительной оптимизации. В итоге Transmeta не смогла конкурировать с Intel и AMD, а к 2009 году компания полностью закрылась.
Эльбрус — великий и ужасный: запускает ракеты, но не Crysis
Сразу оговорюсь, что мне нравится архитектура Эльбрус и одноименные процессоры от российской компании МЦСТ. Желаю им добра и процветания. Так что если вам покажется, что я предвзят — вам не покажется :) Вторая оговорка: на Хабре очень много написано про Эльбрус, а тема настолько огромная, что можно написать пару томов. Так что надолго останавливаться не будем, обсудим лишь самое интересное.
Итак, помимо очевидного (в честь горы) есть и другой вариант расшифровки названия: «Elbrus» — акроним от англ. ExpLicit Basic Resources Utilization Scheduling — «явное планирование использования основных ресурсов».
Корни этой технологии тянутся ещё из СССР, первую версию разработали в Институте точной механики и вычислительной техники (ИТМиВТ) в 1970-х годах под руководством Бориса Бабаяна.
Советские суперкомпьютеры серии Эльбрус применяли в военной и космической сферах. В 1980-е годы были попытки создать процессоры-конкуренты системам от DEC и IBM. Эльбрус-1 (1979) и Эльбрус-2 (1984) использовались в системе ПРО "А-135 Амур", защищавшей Москву от ядерных ударов. Кстати, Эльбрус-2 был 64-разрядной суперскалярной системой — довольно революционное решение для 1980-х годов.
Но после распада Союза разработки замедлились, рынок открылся, начались поставки западных решений. В итоге, Юра, мы всё… отечественная микроэлектроника ушла в тень, а Эльбрус на сегодня — нишевая технология.
В новейшей истории Эльбрус пытались воскресить, но санкции 2022 года закрыли доступ к производству на фабриках TSMC, а в 2024 году МЦСТ передали во внешнее управление (очевидно, что начались серьёзные внутренние проблемы). После этого МЦСТ объявила об открытии исходных кодов ядра Linux и системных библиотек архитектуры Эльбрус, что вроде как должно помочь развитию сообщества разработчиков и поддержке открытого ПО. Неплохой шаг к экосистеме, хоть и запоздалый. Поглядим.
А теперь к главным фишкам Эльбруса — перед нами не просто VLIW, а полная программная модель. Это значит, что функционал, который в других архитектурах как правило работает аппаратно, здесь выполняются с помощью микрокода — низкоуровневого программного слоя, который управляет процессором.
Эльбрусы используют автоматическое динамическое планирование команд на уровне микрокода, что на практике снижает зависимость от компилятора (привет, Itanium или классический VLIW), улучшает предсказуемость исполнения и снижает нагрузку на компилятор. Даже если компилятор неидеально оптимизировал код, процессор всё ещё может самостоятельно переупорядочить инструкции для эффективного исполнения.
Вот эта особенность и позволяет Эльбрусам эффективно работать с неоптимизированным для VLIW кодом, включая инструкции x86. Динамическое планирование команд в Эльбрусе — это ключевой момент архитектуры, попытка решить главный недостаток VLIW. Itanium пытался в спекулятивное исполнение и предсказание ветвлений (EPIC), но подход Эльбруса кажется перспективнее.
Ещё упомяну огромный регистровый файл (массив регистров в процессоре).
В современных Эльбрусах (например, Эльбрус-8С, Эльбрус-16С) есть 256 64-битных регистров общего назначения (разделения на целочисленные и вещественные регистры, как в Itanium, нет). Из них 32 регистра предназначены для глобальных данных, а 224 регистра — для локальных переменных и стека процедур. Это намного больше, чем в x86-64, где обычно 16 штук 64-битных регистров общего назначения. Плюс 32 2-битных регистра (предикаты).
В Itanium было 128 регистров для целочисленных и 128 вещественных данных. На как я писал выше в статье, механизм RSE (регистровый стек) занимал переменное количество регистров, так как он динамически управлял их распределением. Типичная конфигурация распределяла примерно половину регистров (около 64 из 128 целочисленных) для этого механизма. Да, это позволяло снизить обращения к памяти, но усложняло компиляцию и добавляло накладные расходы — компилятор не всегда имел доступ ко всей регистровой архитектуре Itanium.
В Эльбрусах же все 256 регистров общего назначения доступны в любой момент — без динамического перераспределения. Это снижает требования к компилятору и минимизирует обращения к памяти.
Ну и упомяну неочевидную проблему Эльбрусов (про очевидные все и так знают) — совместимость между поколениями.
Несмотря на общую архитектуру, каждое новое поколение процессоров Эльбрус вносит изменения в формат команд, внутреннюю микроархитектуру и оптимизацию VLIW-команд. Это влияет на совместимость двоичного кода. Да, у Эльбрусов переменная длина VLIW-слова (например, 128 или 256 бит), но способы упаковывания инструкций внутри могут меняться между поколениями. В процессорах могут изменяться алгоритмы исполнения и декодирования, из-за чего бинарный код, оптимизированный под одно поколение, может работать хуже или вообще не запускаться на другом.
Официально МЦСТ говорит, что старый бинарный код обычно исполняется на новых процессорах, но оптимальная производительность достигается только после перекомпиляции.
Наследие Эльбруса на сегодня скромное: есть рабочие устройства, но вы не готовы к их названиям :)
Если по-человечески, то это ноутбук для подводных лодок и всего подобного. А есть вот такой вариант.
Производительность всего этого добра оставляет желать лучшего. Про динамический двоичный транслятор для совместимости с x86 софтом я уже сказал — работает относительно нормально, но значительно хуже нативного исполнения на x86. Чтобы вы понимали: восьмиядерный Эльбрус-8С (2016 год) на тактовой частоте 1.3 ГГц в режиме трансляции выдаёт производительность примерно на уровне Intel Core 2 Duo 2006 года. Ремарка: оценка приблизительная, детальных бенчмарков в открытом доступе мало.
На самом деле для техники, работающей в критических инфраструктурах, стратегических объектах и т.п., это неплохой вариант. Закрытость и проприетарность технологий полезны для кибербеза, а производительность Core Ultra 9 в его задачах не нужна. Здесь важен принцип «лучше старое/непроизводительное, но надёжное».
Например, в авионике Airbus и Boeing до сих пор можно встретить процессоры, которые были актуальны в 1990-е годы, а иногда и раньше: Motorola 68000 (1980-е), PowerPC (2000-е), Texas Instruments TMS320 (с 1983 г. и по сей день в новых версиях), LEON (архитектура SPARC, авиация, космос, устойчивы к радиации).
Такие дела. Будем закругляться.
К выводам
История VLIW — это история архитектуры, которая могла изменить индустрию, но всё пошло не так. Архитектура, несмотря на свою элегантность и теоретические преимущества в производительности и энергоэффективности, так и не стала мейнстримом в процессоростроении. Главная проблема — зависимость от компилятора, который должен идеально оптимизировать код для эффективного исполнения.
И вместо вдумчивой оптимизации вендоры выбрали тупиковый путь производительности железа. VLIW во всех её видах не повезло оказаться под водопадом плохих реализаций и неудачных обстоятельств.
Провал Itanium — пример того, как большие деньги и мастодонты, вроде Intel и HP, не могут преодолеть фундаментальные ограничения архитектуры и не могут развивать продукт без экосистемы. Что из этого важнее — решайте сами.
Но наследие VLIW живо, особенно в узкоспециализированных нишах, где компиляторы могут раскрыть её потенциал: DSP, Эльбрус, мобильные Qualcomm Hexagon и т.д.
Спасибо, что осилили этот лонгрид, друзья. Не забудьте указать на ошибки автора в комментариях — это самый быстрый путь к просветлению :) А ещё дайте знать, если хотите разбор другой архитектуры — это можно устроить.