1.3.Микроуровневый параллелизм
При исполнении программы регулярно встречаются ситуации, когда исходные данные для i-й операции вырабатываются заранее, например, при выполнении (i-2)-й или (i-3)-й операции. Тогда при соответствующем построении вычислительной системы можно совместить во времени выполнение i-й операции с выполнением (i-1)-й, (i-2)-й, ... операций. В таком понимании скалярный параллелизм похож на параллелизм независимых ветвей, однако они очень отличаются длиной ветвей и требуют разных вычислительных систем. Это представлено на рис. 1.3.
Рис. 1.3. Предварительная подготовка операндов для команды i
Рассмотрим пример. Пусть имеется программа для расчета ширины запрещенной зоны транзистора и в этой программе есть участок – определение энергии примесей по формуле:
Тогда последовательная программа для вычисления E будет такой:
Здесь имеется параллелизм, но при записи на языке программирования у нас нет возможности явно отразить его. Явное представление параллелизма для вычисления E задается ярусно-параллельной формой (ЯПФ) (рис. 1.4).
Рис. 1.4. Параллельное вычисление функции
Ширина параллелизма первого яруса этой ЯПФ (первый такт) сильно зависит от числа операций, включаемых в состав ЯПФ. Так, в примере для l1 = 4 параллелизм первого такта равен двум, для l1 = 12 параллелизм равен пяти.
Поскольку это параллелизм очень коротких ветвей, данный вид параллелизма должен автоматически выявляться аппаратурой ЭВМ в процессе выполнения машинной программы. Параллельное выполнение команд достигается при помощи вычислительного конвейера.
Введение конвейера
Принцип конвейера применительно к процессорам означает, что если разбить выполнение машинной инструкции на несколько этапов, то тактовая частота (а вернее, скорость, с которой процессор забирает данные на исполнение и выдает результаты) будет обратно пропорциональна времени выполнения самого медленного этапа. Если это время удастся сделать достаточно малым (а чем больше этапов на конвейере, тем они короче), то будет возможность резко повысить тактовую частоту, а значит, и производительность процессора.
Процедуру выполнения практически любой инструкции можно разбить как минимум на пять непересекающихся этапов:
-
Выборка инструкции (FETCH) из памяти. Из программы извлекается инструкция, которую нужно выполнить.
-
Декодирование инструкции (DECODE). Процессор "соображает", что от него хотят, и переправляет запрос на нужное исполнительное устройство.
-
Подготовка исходных данных для выполнения инструкции.
-
Собственно выполнение инструкции (EXECUTE).
-
Сохранение полученных результатов.
Конвейеризация потенциально применима к любой процессорной архитектуре, независимо от набора команд и положенных в ее основу принципов. Даже самый первый x86-процессор, Intel 8086, уже содержал своеобразный примитивный "двухстадийный конвейер" – выборка новых инструкций (FETCH) и их исполнение осуществлялись в нем независимо друг от друга. Однако реализовать что-то более сложное для CISC-процессоров оказалось трудно: декодирование неоднородных CISC-инструкций и их очень сильно различающаяся сложность привели к тому, что конвейер получается чересчур замысловатым, катастрофически усложняя процессор. Подобных трудностей у RISC-архитектуры гораздо меньше (а SPARC и MIPS, например, и вовсе были специально оптимизированы для конвейеризации), так что конвейеризированные RISC-процессоры появились на рынке много раньше, чем аналогичные x86.
Недостатки конвейера очевидны, и реализация грамотно организованного конвейера является не простой задачей. Существует три основных проблемы:
-
Необходимость наличия блокировок конвейера. Дело в том, что время исполнения большинства инструкций может очень сильно варьироваться. Скажем, умножение (и тем более деление) чисел требуют (на стадии EXECUTE) нескольких тактов, а сложение или побитовые операции – одного такта; а для операций Load и Store, которые могут обращаться к разным уровням кэш-памяти или к оперативной памяти, это время вообще не определено (и может достигать сотен тактов). Соответственно, должен быть какой-то механизм, который бы "притормаживал" выборку и декодирование новых инструкций до тех пор, пока не будут завершены старые. Методов решения этой проблемы много, но их развитие приводит к одному – в процессорах прямо перед исполнительными устройствами появляются специальные блоки-диспетчеры (dispatcher), которые накапливают подготовленные к исполнению инструкции, отслеживают выполнение ранее запущенных инструкций и по мере освобождения исполнительных устройств отправляют на них новые инструкции. Даже если исполнение займет много тактов – внутренняя очередь диспетчера позволит в большинстве случаев не останавливать подготавливающий все новые и новые инструкции конвейер (Новые инструкции тоже не каждый такт удается декодировать, так что возможна и обратная ситуация: новых инструкций за такт не появилось, и диспетчер отправляет инструкции на выполнение "из старых запасов"). Так в процессоре возникает разделение на две независимо работающие подсистемы: Front-end (блоки, занимающиеся декодированием инструкций и их подготовкой к исполнению) и Back-end (блоки, собственно исполняющие инструкции).
-
Необходимость наличия системы сброса процессора. Поскольку операции FETCH и EXECUTE всегда выделены в отдельные стадии конвейера, то в тех случаях, когда в программном коде происходит разветвление (условный переход), зачастую оказывается, что по какой из веток пойти – пока неизвестно: инструкция, вычисляющая код условия, еще не выполнена. В результате процессор вынужден либо приостанавливать выборку новых инструкций до тех пор, пока не будет вычислен код условия (а это может занять очень много времени и в типичном цикле страшно затормозит процессор), либо, руководствуясь соображениями блока предсказания переходов, "угадывать", какой из переходов скорее всего окажется правильным.
-
Наконец, конвейер обычно требует наличия специального планировщика (scheduler), призванного решать конфликты по данным. Если в программе идет зависимая цепочка инструкций (когда инструкция-2, следующая за инструкцией-1, использует для своих вычислений данные, только что вычисленные инструкцией-1), а время исполнения одной инструкции (от момента запуска на стадию EXECUTE и до записи полученных результатов в регистры) превосходит один такт, то мы вынуждены придержать выполнение очередной инструкции до тех пор, пока не будет полностью выполнена ее предшественница. К примеру, если мы вычисляем выражение вида с сохранением результата в переменной , то процессор, выполняя соответствующую выражению цепочку из двух команд типа ; , должен вначале дождаться, пока первая инструкция сохранит результат умножения , и только потом прибавлять к полученному результату число С. Цепочки зависимых инструкций в программах – скорее правило, нежели исключение, а исполнение команды с записью результата в регистры за один такт – наоборот, скорее исключение, нежели правило, поэтому в той или иной степени с проблемой зависимости по данным любая конвейерная архитектура обязательно сталкивается. Оттого-то в конвейере и появляются сложные декодеры, заранее выявляющие эти зависимости, и планировщики, которые запускают инструкции на исполнение, выдерживая паузу между запуском главной инструкции и зависимой от нее.
Несмотря на все плюсы идеи конвейера в процессоре, реализовать его даже в простом варианте чрезвычайно трудно. Но выгода от конвейеризации так велика, что приходится с этими трудностями мириться, ведь ничего лучшего до сих пор не придумано.
В 1991-92 годах корпорация Intel, освоив производство сложнейших кристаллов с более чем миллионом транзисторов, выпустила i486 – классический CISC-процессор архитектуры x86, но с пятистадийным конвейером. Чтобы можно было оценить этот рывок, приведем две цифры: тактовую частоту по сравнению с i386 введение конвейера позволило увеличить втрое, а производительность на единицу частоты – вдвое. В i386 многие инструкции выполнялись за несколько тактов; а в i486 среднее "время" исполнения инструкции в тактах удалось снизить почти вдвое. Ядро i486 было значительно сложнее, чем i386, но быстро растущие технологические возможности кремниевой технологии уже через пару лет позволили освоить производство i486 всем желающим. Но к тому моменту RISC-архитектуры сделали еще один шаг вперед – к суперскалярным процессорам.
|
