Влияние конвейерной обработки

Идея конвейера состоит в том, что производительность цепочки последовательных действий определяется не сложностью этой цепочки, а лишь длительностью самой сложной операции. Конвейеризация потенциально применима к любой процессорной структуре, независимо от набора команд и положенных в ее основу принципов. Однако реализовать конвейерную обработку для CISC-процессоров оказалось трудно: декодирование неоднородных CISC-команд и их очень сильно различающаяся сложность привели к тому, что конвейер получается сложным. Подобных трудностей у RISC-архитектуры гораздо меньше (все команды одинакового размера, команды обрабатывают операнды, расположенные только в регистрах, поля операндов всегда на одних и тех же местах, команды обращения в оперативную память выделены в отдельную группу и т.п.).

Недостатки конвейера неочевидны, но, как обычно и бывает, из-за нескольких "мелочей" реализовать грамотно организованный конвейер совсем не просто. Основных проблем три.

1. Необходимость наличия блокировок конвейера. Дело в том, что время выполнения большинства команд может очень сильно отличаться. Скажем, умножение (и тем более деление) чисел требуют (на стадии ВЫПОЛНЕНИЕ ) нескольких тактов, а сложение или поразрядные операции - одного такта; а для операций LOAD и STORE, которые могут обращаться к разным уровням кэш-памяти или к оперативной памяти, это время вообще не определено (и может достигать сотен тактов). Соответственно, должен быть какой-то механизм, который бы "притормаживал" выборку и декодирование новых команд до тех пор, пока не будут завершены старые. Методов решения этой проблемы много. Их использование приводит к тому, что в ядрах процессоров прямо перед исполнительными устройствами появляются специальные блоки-диспетчеры (dispatcher), которые накапливают подготовленные к выполнению команды, отслеживают выполнение ранее запущенных команд и по мере освобождения исполнительных устройств отправляют на них новые команды. Даже если выполнение займет много тактов - внутренняя очередь диспетчера позволит в большинстве случаев не останавливать подготавливающий все новые и новые команды конвейер. Новые команды тоже не каждый такт удается декодировать, так что возможна и обратная ситуация: новых команд за такт не появилось, и диспетчер отправляет команды на выполнение "из старых запасов". Так в ядре процессора возникает разделение на две независимо работающие подсистемы: Генерация команд (блоки, занимающиеся декодированием команд и их подготовкой к выполнению) и Выполнение команд (блоки, собственно выполняющие команды).

2. Необходимость наличия системы сброса процессора. Поскольку операции Выборка команды и Выполнение всегда выделены в отдельные стадии конвейера, то в тех случаях, когда в программе происходит разветвление (условный переход), зачастую оказывается, что по какой из веток пойти пока неизвестно: команда, вычисляющая код условия, еще не выполнена. Вот здесь-то и нужны режимы выставления флагов, которые отсутствуют в CISC-архитектурах. В результате ядро процессора вынуждено либо приостанавливать выборку новых команд до тех пор, пока не будет вычислен код условия (а это может занять очень много времени и в типичном цикле значительно затормозит ядро процессора), либо, руководствуясь соображениями блока предсказания переходов, "угадывать", какой из переходов скорее всего окажется правильным.

3. Конвейер обычно требует наличия специального планировщика, призванного решать конфликты по данным. Если в программе идет зависимая цепочка команд (когда команда 2, следующая за командой 1, использует для своих вычислений данные, только что вычисленные командой 1), а время выполнения одной команды (от момента запуска на стадию Выполнение и до записи полученных результатов в регистры) больше одного такта, то вынуждены придержать выполнение очередной команды до тех пор, пока не будет выполнена предшествующая команда. Цепочки зависимых команд в программах - скорее правило, нежели исключение, а выполнение команды с записью результата в регистры за один такт - наоборот, скорее исключение, нежели правило, поэтому в той или иной степени с проблемой зависимости по данным любая конвейерная структура обязательно сталкивается. Оттого-то в конвейере и появляются сложные декодеры, заранее выявляющие эти зависимости, и планировщики, которые запускают команды на выполнение, выдерживая паузу между запуском главной команды и зависимой от нее.

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

Реализация конвейера, особенно декодеров, для RISC-процессоров оказалась более простой, чем для CISC-процессоров. До тех пор, пока в одной микросхеме было ограниченное число транзисторов, RISC-подход имел преимущество. Однако когда количество транзисторов в одной микросхеме превысило цифру миллион, это преимущество стало исчезать.

Например, в 1991–1992 годах фирма Intel, освоив производство кристаллов с более чем миллионом транзисторов, выпустила процессор i486 - классический CISC-процессор архитектуры IA-32, но с пятистадийным конвейером. Чтобы оценить этот рывок, приведем две цифры: частоту по сравнению с процессором i386 введение конвейера позволило увеличить втрое, а производительность на единицу частоты – вдвое. В процессоре i386 многие команды выполнялись за несколько тактов, а в процессоре i486 среднее "время" выполнения команды в тактах удалось снизить почти вдвое. Правда, расплатой за это стала сложность ядра процессора i486; но такие "мелочи" по меркам индустрии процессоров – пустяк.

Поиск по сайту: