Принцип явного параллелизма

Глава 22. Особенности архитектуры EPIC

Принцип явного параллелизма

Архитектура EPIC коренным образом отличается от архитектур IA-32/64, ARM всех версий. Основная концепция архитектуры EPIC- это параллелизм на уровне команд, или явный параллелизм.

Для увеличения числа команд, выполняемых за такт и обеспечения высокой производительности, разработчики процессоров с архитектурой типа IA-32/64 использовали различные аппаратные ухищрения, такие, как:

внутреннее разбиение CISC-команд на простые RISC-команды;

использование большого регистрового файла, несмотря на то, что программисту может быть доступна только малая его часть. Например, в лучших процессорах фирмы Intel регистровый файл состоит из более чем 100 регистров при доступных программисту 16 регистрах.

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

предсказание переходов и предположительное выполнение;

предвыборка данных и т. п.

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

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

Основные особенности архитектуры EPIC следующие:

команды упакованы по три в 128-разрядный пакет для быстрейшей обработки (рис. 22.1).

Рис. 22. 1. Формат пакета команд EPIC. Т – маска, указывающая на возможность параллельного выполнения этого и последующих пакетов команд

Формат одной команды обработки данных в регистрах пакета приведен на рис. 22.2.

Рис. 22.2. Формат одной команды обработки данных в регистрах

В любом случае формат команд EPIC не имеет ничего общего с форматом команд всех других архитектур. Например, команды архитектуры IA-32/64 могут иметь длину от одного байта до 16 байт, и ядро процессора должно последовательно декодировать каждую команду после определения её границ.

В архитектуре EPIC каждый 128-разрядный пакет содержит поле (template) длиной в несколько разрядов, формируемое компилятором. Это поле указывает ядру процессора, какие из команд могут выполняться параллельно. Ядру процессора не нужно анализировать поток команд в процессе выполнения для выявления "скрытого параллелизма". Вместо этого наличие параллелизма определяет компилятор и помещает информацию в каждый пакет команд. Каждая команда (как для целочисленных вычислений, так и для вычислений с плавающей точкой) содержит три 7-разрядных поля для указания регистра общего назначения (РОН). По сравнению с процессорами с архитектурой IA-32/64, у которых всего 16 целочисленных регистров общего назначения (РОН) и стек глубиной 8 для данных с плавающей точкой, ядра процессоров с архитектурой EPIC имеют намного больше РОН и, соответственно, должны реже простаивать из-за "нехватки регистров".

Компиляторы для процессоров с архитектурой EPIC используют технологию "отмеченных команд" (predication) для устранения потерь производительности из-за неправильно предсказанных переходов и необходимости пропуска участков программы после ветвлений. Когда ядро процессора встречает "отмеченное" ветвление в процессе выполнения программы, оно начинает одновременно выполнять все ветви. После того, как определена "истинная" ветвь, ядро процессора сохраняет необходимые результаты и сбрасывает остальные.

Компиляторы для архитектуры EPIC просматривают исходную программу с целью поиска команд, использующих данные из оперативной памяти. Найдя такую команду, они добавляют пару команд - команду предварительной загрузки (speculative loading) и проверки загрузки (speculative check). Во время выполнения программы первая из команд загружает данные из оперативной памяти до того, как они понадобятся программе. Вторая команда проверяет, успешно ли произошла загрузка, перед тем, как разрешить программе использовать эти данные. Предварительная загрузка позволяет уменьшить потери производительности из-за задержек при доступе к оперативной памяти, а также повысить параллелизм.

Из всего вышесказанного следует, что компиляторы для процессоров архитектуры EPIC должны быть намного "умнее" и лучше знать структуру ядер процессора, программу для которых они вырабатывают. Существующие микросхемы процессоров, в том числе и RISC-процессоры, производят гораздо больше оптимизации на этапе выполнения программ, даже при использовании оптимизирующих компиляторов. Архитектура EPIC перекладывает практически всю работу по оптимизации потока команд на компилятор. Таким образом, программы, скомпилированные для одного поколения процессоров архитектуры EPIC, на процессорах следующего поколения без перекомпиляции могут выполняться неэффективно. Это ставит перед разработчиками и поставщиками программного обеспечения нелёгкую задачу по выпуску нескольких версий выполняемых файлов для достижения максимальной производительности.

Другим, не очень приятным следствием, является увеличение размеров программ, так как команды архитектуры EPIC длиннее, чем 32-разрядные стандартные RISC-команды. Компиляция при этом будет занимать больше времени, поскольку архитектура EPIC, как уже было сказано, требует от компилятора гораздо больше действий.

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

Технология "отмеченных команд" является наиболее характерным примером "дополнительной ноши", перекладываемой на компиляторы. Эта технология является центральной для устранения ветвлений и управления параллельным выполнением команд.

Обычно компилятор транслирует оператор ветвления (например, IF-THEN-ELSE) в блоки машинной программы, расположенные последовательно в потоке. В зависимости от условий ветвления ядро процессора выполняет один из этих блоков и перескакивает через остальные. Современные ядра процессоров стараются предсказать результат вычисления условий ветвления и предварительно выполняют предсказанный блок. При этом в случае ошибки много тактов тратится впустую. Сами блоки зачастую весьма малы - две или три команды, - а ветвления встречаются в программах в среднем каждые шесть команд. Такая структура программы делает крайне сложным ее параллельное выполнение.

Когда компилятор для архитектуры EPIC находит оператор ветвления в исходной программе, он исследует ветвление определяя, стоит ли его "отмечать". Если такое решение принято, компилятор помечает все команды, относящиеся к одному пути ветвления, уникальным идентификатором, называемым предикатом (predicate). Например, путь, соответствующий значению условия ветвления TRUE, помечается единицей в предикатном регистре Р1, а каждая команда пути, соответствующего значению условия ветвления FALSE – нулем в предикатном регистре Р2. Система команд архитектуры EPIC определяет для каждой команды один одноразрядный предикатный регистр для хранения этого предиката. Таким образом, одновременно могут быть использованы 64 различных предиката. После того, как команды "отмечены", компилятор определяет, какие из них могут выполняться параллельно. Это опять требует от компилятора знания структуры конкретного ядра процессора, поскольку различные ядра процессоров с архитектурой EPIC могут иметь различное число и тип функциональных устройств. Кроме того, компилятор, естественно, должен учитывать зависимости по данным (две команды, одна из которых использует результат другой, не могут выполняться параллельно). Поскольку каждый путь ветвления заведомо не зависит от других, какое-то "количество параллелизма" почти всегда будет найдено.

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

После этого компилятор транслирует исходную программу в машинный вид и упаковывает команды в 128-разрядные пакеты. В пакете (в поле шаблона) указывается не только какие команды могут выполняться независимо, но и какие команды из следующего пакета могут выполняться параллельно. Команды в пакетах не обязательно должны быть расположены в том же порядке, что и в машинном виде, и могут принадлежать к различным путям ветвления. Компилятор может также помещать в один пакет зависимые и независимые команды, поскольку возможность параллельного выполнения определяется шаблоном пакета. В отличие от некоторых ранее существовавших архитектур со сверхдлинными словами команд (VLIW), архитектура EPIC позволяет не добавлять команды "нет операции" для дополнения пакетов.

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

Разумеется, в какой-то момент ядро процессора наконец вычислит значение условия ветвления в рассматриваемом операторе IF-THEN-ELSE. Предположим, оно равно TRUE, следовательно, правильный путь отмечен 1 в предикатном регистре Р1. Ядро процессора записывает 1 в предикатный регистр Р1 и 0 - в предикатный регистр Р2.

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

Технология "отмеченных команд" существенно снижает негативное влияние ветвлений на машинном уровне. В то же время, если компилятор не "отметил" ветвление, ядро процессора с архитектурой EPIC действует практически так же, как и, например, современные ядра процессоров с архитектурой IA-32/64: пытается предсказать путь ветвления и т.д. Испытания показали, что описанная технология позволяет устранить более половины ветвлений в типичной программе, и, следовательно, уменьшить более чем в два раза число возможных ошибок в предсказаниях.

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

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

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

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

Поддержка режима IA-32/64

Ядра процессоров с архитектурой EPIC обеспечивали полную программную совместимость с программами архитектуры IA-32/64, но, к сожалению, скорость их выполнения оставляла желать лучшего. Команды архитектуры IA-32/64 аппаратно преобразовывались в последовательности команд архитектуры EPIC, которые из-за отсутствия в аппаратуре динамической оптимизации выполняются медленно. Запускать на таком процессоре имеет смысл только приложения архитектуры IA-32/64, которые не критичны к скорости выполнения.