Производительность современных микропроцессоров

А. Б. Галазин, А. М. Степаненков, Е. В. Ступаченко
ПРОГРАММНАЯ ПРЕДВАРИТЕЛЬНАЯ ПОДКАЧКА КОДА
ДЛЯ МИКРОПРОЦЕССОРА «ЭЛЬБРУС»
1. Введение
Производительность современных микропроцессоров существенно зависит от
эффективной загрузки их вычислительных устройств. Наиболее известным способом
обеспечения непрерывной работы микропроцессора и снижения количества
блокировок конвейера является организация иерархической системы памяти с
использованием кэшей разных уровней [1, 2]. Кроме того, используются программные,
аппаратные и комбинированные методы предварительной подкачки данных [3-7].
Совокупность этих подходов позволяет обеспечить практически полную загрузку
вычислительных устройств микропроцессора для некоторых классов задач, например
для научных приложений, в которых обрабатываются значительные объемы данных
высокой локальности. Однако, как показывают исследования, эти методы оказываются
неэффективными для больших системных приложений, таких как операционные
системы, оконные менеджеры и базы данных [8-10]. В этих приложениях
обрабатываются значительные объемы информации, которая хранится в структурах,
слабо поддающихся анализу во время компиляции, а код приложения состоит из
больших ациклических участков. Потребность в повышении эффективности работы
микропроцессора во время обработки этих приложений определяется их частым
использованием в реальной жизни.
В отличие от научных приложений, в которых значительное влияние на
производительность оказывают блокировки по ожиданию данных [11], в системных
приложениях более важную роль играют блокировки по ожиданию кода [10].
Подобные блокировки возникают при передаче управления на инструкцию, которая
отсутствует в буфере инструкций, в результате чего микропроцессор вынужден
посылать запрос в оперативную память, что приводит к простою конвейера.
Для уменьшения блокировок по ожиданию кода предложены различные
аппаратные и комбинированные подходы.
Большинство авторов предлагают аппаратные методы предварительной
подкачки кода, основываясь на предыстории запросов от буфера инструкций. Такие
методы предполагают реализацию в микропроцессоре устройства, ответственного за
ведение истории и своевременную предварительную подкачку [12].
В комбинированных (программно-аппаратных) методах предлагается проводить
подкачку с помощью специальных инструкций и контролировать обращения в память
от этих инструкций с помощью аппаратного фильтра в микропроцессоре, с тем, чтобы
избежать ситуаций обращения за уже подкачанным кодом [13,14].
Эффективность предлагаемых методов в значительной степени определяется
аппаратными характеристиками предлагаемых устройств и размерами буфера
инструкций. Эти методы при заявленных характеристиках показывают хорошую
эффективность, однако в силу необходимости добавления в микропроцессор устройств,
работающих по сложным алгоритмам, их реализация представляет значительную
сложность.
Программные методы предварительной подкачки кода практически не
рассматриваются в литературе, тем не менее, программная предварительная подкачка
важна для микропроцессоров, реализующих архитектуру с широким командным
словом (VLIW) [15, 16], поскольку для таких микропроцессоров весь анализ
возможности параллельного исполнения инструкций передан компилятору.
В данной работе рассмотрен программный метод предварительной подкачки
кода для микропроцессора «Эльбрус» [17, 18]. Описываются аппаратные особенности
архитектуры и особенности исполняемого кода, созданного оптимизирующим
компилятором, обусловливающие потребность в предварительной подкачке.
Эффективность метода исследовалась на различных задачах пакетов Spec95, Spec2000
[19], в которых ожидание кода может вносить значительный вклад в итоговое время
исполнения программы. Все приведенные результаты получены на вычислительном
комплексе с микропроцессором «Эльбрус».
2. Аппаратные особенности платформы
Микропроцессор «Эльбрус» реализует архитектуру с широким командным
словом. Необходимость в эффективной предварительной подкачке обусловлена
следующими свойствами микропроцессора:
1. широкая команда;
2.
наличие инструкций подготовки передачи управления;
3.
наличие буфера инструкций размером 64 KB.
В микропроцессоре «Эльбрус» широкая команда не имеет фиксированной
длины (максимальная длина 64 байта), и представлена как переменный командный
набор управляющих слогов заданного формата. Под слогом понимается набор битов
команды микропроцессора, который содержит некоторую часть информации о
команде. Более подробно описание широкой команды представлено в работе [20]. Для
дальнейшего изложения важно то, что широкая команда имеет переменную длину,
вычисляемую на этапе компиляции.
Микропроцессор «Эльбрус» обладает механизмом подкачки кода, который
задействуется при наличии в коде специальных инструкций. Данные инструкции
называются инструкциями подготовки передачи управления (disp) и отделены от
инструкций передачи управления (branch, call, return). Инструкции disp запускают
механизм загрузки кода по адресу перехода. Для хранения адресов перехода в
микропроцессоре «Эльбрус» предусмотрены 3 регистра передачи управления, в
которые инструкции disp загружают адреса перехода, а инструкции передачи
управления загруженные адреса считывают и выполняют переход. Подобное
разделение позволяет осуществлять передачу управления за один такт, так как
подготовку можно сделать заранее, на фоне вычислений, которые должны исполниться
до перехода.
Используя инструкции подготовки передачи управления, можно организовать
предварительную подкачку кода даже в случае отсутствия перехода.
Буфер инструкций микропроцессора «Эльбрус» предназначен для загрузки
инструкций как по основной ветви выполняемой программы, так и в направлении
переходов (в случае использования инструкций подготовки передачи управления), а
также для хранения наиболее часто используемых кодов. Наличие буфера инструкций
позволяет резко уменьшить время простоя устройства управления и исполнительных
конвейеров процессора, а также существенно снижает нагрузку на устройство
обращения в память.
На логическом уровне буфер инструкций организован как однопортовая память
из 256 строк по 256 байт. При необходимости загрузить код буфер инструкций
посылает сначала запрос в кэш второго уровня, а в случае отсутствия нужного кода в
кэше запрос отправляется в оперативную память. Как было сказано, инструкции
подготовки передачи управления позволяют организовать загрузку кода в буфер
инструкций, при этом размер загружаемого кода не может превышать размеров одной
строки буфера, то есть 256 байт. Таким образом, в случае первого перехода после
передачи управления в буфере инструкций находится не более 256 байт кода, который
будет исполняться по прямой ветви, такая же ситуация будет наблюдаться, если код
исполняется недостаточно часто и не запоминается буфером инструкций.
Далее будут описаны особенности исполняемого кода, создаваемого
оптимизирующим компилятором для микропроцессора «Эльбрус», из которых будет
следовать необходимость предварительной подкачки кода.
3. Особенности исполняемого целевого кода
Из организации буфера инструкций микропроцессора «Эльбрус» следует, что
если в исполняемом коде имеется значительное количество участков без инструкций
передач управления, то в некоторых приложениях будут наблюдаться значительные
блокировки по ожиданию данных. В этой части работы мы покажем, что в целях учета
особенностей архитектуры и минимизации времени исполнения оптимизирующий
компилятор создает именно такой код.
Введем следующие определения:
 начальной широкой командой будем называть широкую команду, на которую
передано управление с помощью одной из инструкций передачи управления;
 непрерывно исполняемым участком кода (Continuous Code Segment) будем
называть последовательно исполняемые широкие команды, начиная с
начальной широкой команды до первой широкой команды, содержащей
инструкцию передачи управления с вероятностью исполнения по профилю
более 90%;
 длина непрерывно исполняемого участка кода – сумма длин широких
команд, входящих в участок.
Будем обозначать непрерывно исполняемый участок кода как CCS, а
непрерывно исполняемый участок кода длины более X байт как CCSL>X .
Для наиболее эффективного анализа возможности параллельного исполнения
инструкций и построения кода, максимально использующего вычислительные
возможности архитектуры, компилятор использует различные преобразования графа
управления. В результате таких преобразований увеличиваются длины CCS.
Потребность в предварительной подкачке возникает, если в задаче имеется
значительное количество CCS, длина которых больше размера строки буфера
инструкций, поскольку в таком случае при попытке исполнить широкую команду, код
которой отсутствует в буфере, конвейер микропроцессора блокируется.
Среди преобразований графа управления, реализованных в оптимизирующем
компиляторе для микропроцессора «Эльбрус», основной вклад в увеличение длин CCS
вносят два: переход к предикатному представлению в рамках глобального
планирования и линеаризация графа управления.
3.1. Глобальное планирование
Одним из существенных свойств архитектуры микропроцессора «Эльбрус»
является поддержка предикатных вычислений и предикатного исполнения. Учет этой
особенности архитектуры в оптимизирующем компиляторе позволяет значительно
повысить производительность вычислительного комплекса. Для использования данного
свойства реализовано специальное преобразование, называемое глобальным
планированием в ациклическом регионе и за пределами ациклического региона.
Преобразование подробно описано в [20]. Стоит отметить, что это преобразование
преобразует поток управления в поток данных с помощью слияния узлов графов
управления в расширенные скалярные участки [20]. В результате удаляются излишние
инструкции передачи управления, что увеличивает длины CCS.
На рис. 1 представлено изменение количества CCSL>256 до преобразования к
количеству CCSL>256 после преобразования для представленных задач. Как видно из
рис. 1, в результате перехода к предикатному представлению наблюдается
значительный рост количества CCSL>256 на всех задачах. В среднем по представленному
набору задач количество таких участков увеличивается в 4,08 раза, что свидетельствует
о необходимости применить предварительную подкачку кода.
3.2. Линеаризация графа управления
Следующим преобразованием, увеличивающим количеством CCSL>256, является
линеаризация графа. Оно минимизирует общее количество инструкций передач
управления, поскольку во всех архитектурах передача управления требует
значительного количества времени микропроцессора, особенно когда требуется
загружать код из памяти. В оптимизирующем компиляторе для микропроцессора
Эльбрус-3М реализован оригинальный алгоритм линеаризации графа управления.
Для описания этого алгоритма понадобятся термины, определения которых даны
ниже.
Провал (провальная дуга) – дуга графа управления, для которой выставлен
признак предпочтительной реализации передачи управления без использования
инструкций передачи управления.
Провальный выход узла – единственная выходная дуга узла графа управления,
являющаяся провальной; на самом деле провальных выходов узла может быть
несколько (несколько выходных дуг одного расширенного скалярного участка с общим
преемником), но, с учетом рассмотрения таких дуг как одной дуги, на логическом
уровне провальный выход у узла всегда один.
Черная дыра – множество узлов графа управления (не обязательно связное),
обладающих счетчиком исполнения (по профильной информации), близким к нулю
[21]. Узел, отнесенный к черной дыре, обрабатывается при обходах, но пропускается
при нумерации.
Компактный регион – множество узлов графа управления, которые должны
быть расположены в результирующем графе в порядке нумерации RPO (reverse post
order [22]); исключение – узлы, отнесенные к черной дыре.
Компактная последовательность (компактное размещение) – последовательность, выстроенная в порядке компактной (RPO) нумерации.
Голова региона – предопределенный узел региона, имеющий самый меньший
номер среди всех узлов региона.
Провальный выход региона – единственная выходная дуга региона, являющаяся
провальной; предшественник этой дуги должен быть последним узлом региона в
линейной последовательности.
Провальная цепочка – линейная последовательность узлов или регионов,
каждый из которых связан с последующим провальной дугой.
Зацикленная провальная цепочка – провальная цепочка в рамках которой
принадлежащий ей узел (регион) может быть достигнут сам из себя; в одномерной
линейной последовательности узлов зацикленная провальная цепочка не реализуется, а
потому является запрещенной.
Начальная провальная цепочка региона – провальная цепочка, начинающаяся с
головы региона и заканчивающаяся узлом (регионом) без провальных выходов или
одним из выходов региона.
Завершающая провальная цепочка региона – провальная цепочка, начинающаяся
с одного из узлов (вложенных регионов) региона и заканчивающаяся провальным
выходом из региона.
Тривиальный регион – регион, в котором начальная провальная цепочка
включает в себя все узлы (вложенные регионы) региона, не принадлежащие черной
дыре. Только в тривиальном регионе начальная провальная цепочка может совпасть с
завершающей провальной цепочкой региона. В нетривиальном регионе такое
совпадение приводит либо к тому, что предшественник провального выхода региона не
является последним узлом региона (и, следовательно, не является провалом), либо к
нарушению свойства головы региона, либо к нарушению свойства компактности
региона.
Закрытая дуга – дуга, исключенная из алгоритма. Например, если группа дуг
рассматривается как одна дуга, то все дуги в ней, кроме одной, считаются закрытыми.
Открытой дугой называется не закрытая дуга.
Разрешенный провал – дуга, которая может быть реализована в виде провала
(без учета топологии). Не являются разрешенными провалами нелокальные и
нестатические передачи управления.
Обратная дуга – дуга, обеспечивающая переход в голову цикла.
Непротиворечивый провал – признак провала для некоторой дуги, не
противоречащий текущим признакам провалов для всех остальных дуг графа
управления; дуга является непротиворечивым провалом при соблюдении всех
следующих условий:
1. дуга является разрешенным провалом;
2. дуга является единственным провальным выходом своего предшественника;
3. дуга является единственным провальным входом преемника;
4. дуга не является обратной дугой;
5. если дуга является входом в регион, то преемник совпадает с головой этого
региона;
6. если дуга является выходом из региона, то она является его единственным
провальным выходом;
7. если дуга является выходом из региона, то либо этот регион является
тривиальным, либо предшественник не принадлежит начальной провальной цепочке
этого региона.
Линеаризация графа управления призвана определить строгий (линейный)
порядок узлов графа в коде и привести все инструкции передачи управления в
соответствие с этим порядком. Очевидно, что линейный порядок для произвольной
топологии может быть определен множеством способов, поэтому основной частью
алгоритма является построение оптимального порядка. Алгоритм линеаризации
состоит из двух фаз: нумерации и связывания. На первой фазе выполняется
последовательная нумерация узлов графа управления, вторая фаза (связывание)
является техническим действием, призванным привести управление в соответствие с
определенным порядком узлов. В частности, вторая фаза должна вставить переход
вместо провала, если провал идет не на следующий (по нумерации) узел или убрать
переход, если он идет на следующий (по нумерации) узел. Единственный случай учета
профильной информации в связывании – выбор игнорируемой дуги в том случае, когда
обе выходные дуги условного разветвления не могут стать провалами.
Все нижеследующее касается фазы нумерации. Алгоритм нумерации преследует
две основные цели: обеспечить компактное размещение циклических подграфов с
большой вероятностью повторения, а также минимизировать общий счетчик
переходов. Минимизация этого счетчика происходит естественным образом при
уменьшении количества инструкций передачи управления. В данном случае
рассматриваются не все инструкции передачи управления, а только инструкции,
передающие управление в пределах процедуры из одной широкой команды в другую
(branch), поскольку только такие инструкции можно удалить, соответствующим
образом определив порядок следования узлов в графе управления.
Общая схема алгоритма построения оптимальной последовательности такова:
a. выделение узлов со счетчиком, близким или равным нулю; такие узлы
помещаются в конец линейной последовательности (черную дыру) и
переходы в эти узлы из узлов, не принадлежащих черной дыре, не
рассматриваются как кандидаты на провалы;
b. выделение среди всего подмножества дуг потенциальных кандидатов на
провалы;
c. группировка выходных дуг расширенных скалярных участков с общим
преемником таким образом, что все выходы расширенного скалярного
участка с общим преемником рассматриваются как один выход с общим
счетчиком;
d. разбиение программы на циклические регионы, образующие дерево
регионов; это действие полезно для обеспечения компактного
расположение узлов циклов в коде; основой региона является некоторый
цикл, но при этом цикл может вообще не стать регионом (например, если
он имеет среднее число итераций, близкое к единице) или в регион может
быть включена только часть цикла (если удается выделить в цикле
существенную по размеру маловероятную область);
e. определение для каждого региона, начиная от самых вложенных,
непротиворечивого множества провальных выходов, а также кандидатов
на провальный выход из региона, который может стать провалом при
обработке одного из охватывающих регионов, при этом множество
провальных
выходов
определяется
таким
образом,
чтобы
максимизировать общий счетчик провалов в регионе; если между
удовлетворением условия компактного размещения региона и
максимизацией общего счетчика провала возникает конфликт,
удовлетворяется
требование
компактного
размещения;
при
возникновении конфликта в определении провалов между дугами
вложенного и охватывающего региона предпочтение отдается
вложенному региону как потенциально более часто выполняемому;
f. нумерация всех узлов графа управления, обеспечивающая компактное
размещение внутренностей компактных регионов, а также соседнее
расположение предшественников и преемников провальных дуг.
В результате работы алгоритма происходит уменьшение количества инструкций
передачи управления за счет выстраивания соответствующей последовательности
узлов. Об этом свидетельствуют результаты, представленные на рис. 2. В среднем
уменьшение количества участков составляет по рассмотренным задачам 12%. В то же
время, возрастает количество CCSL>256, что видно из рис. 3.
На рис. 4 показана доля в процентах CCSL>256 среди всех CCS программы для
некоторых задач из пакета Spec95 после всех преобразований и непосредственно перед
генерацией исполняемого кода. В среднем по рассмотренным задачам насчитывается
12% CCSL>256. Такое их количество является достаточным основанием для применения
предварительной подкачки кода.
4. Предварительная подкачка кода
Как было показано выше, в задачах пакета Spec95 имеется довольно Это
значительное количество CCSL>256. Это свидетельствует о том, что при их выполнении
возможны существенные потери производительности из-за блокировок конвейера по
ожиданию данных. Так, например, в задачах 126.gcc и 147.vortex. подобные блокировки
составили 23% и 12.4% времени исполнения соответственно.
Для минимизации количества блокировок и решения проблемы потери
производительности в оптимизирующем компиляторе для микропроцессора «Эльбрус»
реализована программная предварительная подкачка кода. Для этого задействованы
инструкции подготовки передачи управления, которые в данной архитектуре
существуют отдельно от инструкций передачи управления. Целью данной оптимизации
является предварительная загрузка кода, исполняемого по прямой ветви, в кэш второго
уровня или непосредственно в буфер инструкций (если код успеет поступить в буфер
инструкций), и, как следствие, уменьшение времени ожидания кода во время
выполнения программы. Стоит также отметить, что при дублировании запроса на
подкачку кода, последний будет отменен аппаратурой как избыточный и не увеличит
нагрузку на устройство обращения в память. Это происходит, если при появлении
непосредственного запроса на загрузку кода запрос от предварительной подкачки еще
не успел завершиться.
Инструкцией подкачки кода будем назвать инструкцию подготовки передачи
управления с указанием адреса, но без фактического перехода.
Алгоритм программной предварительной подкачки работает со следующим
параметрами:
1. D – расстояние до подкачиваемого кода в блоках по 256 байт;
2. S – расстояние в широких командах между инструкциями подкачки,
использующими одинаковый регистр передачи управления;
3. Pf – отношение счетчика (по профилю) узла графа управления, в котором
находится подкачиваемый код и счетчика (по профилю) узла графа
управления, в котором стоит соответствующая инструкция подкачки;
4. Pc – вероятность (по профилю) вызова процедуры.
Следует отметить, что в силу аппаратных особенностей S не может быть менее
4, в противном случае первая инструкция будет отменена аппаратурой.
После задания параметров основные шаги алгоритма заключаются в
следующем:
1. определение для каждого узла графа управления доступных для
использования предварительной подкачкой регистров передачи управления;
2. определение для каждого узла графа управления необходимости
предварительной подкачки находящегося в нем кода;
3. определение для каждого узла графа управления возможности вставить
инструкцию предварительной подкачки;
4. добавление инструкций предварительной подкачки с учетом расстояния S в
том случае, если отношение счетчика узла графа управления, в котором
стоит подкачка к счетчику узла управления, код которого она подкачивает,
не превосходит 1/Pf, и если расстояние до подкачиваемого кода превосходит
D;
5. удаление инструкции предварительной подкачки, если между подкачиваемой
областью и подкачкой стоит вызов процедуры, вероятность которого более
чем Pc.
На шаге 2 отсекаются узлы внутренних циклов и узлы многоитерационных
циклов, поскольку код таких узлов в силу частой повторяемости будет сохранен в
кэше.
Существенным ограничением для применения предварительной подкачки кода
является необходимость работать только с доступными регистрами передачи
управления. Поскольку описанная оптимизация является одним из последних этапов
работы компилятора, регистры передачи управления уже распределены специальным
алгоритмом.
Целью данного алгоритма является оптимальное распределение инструкций
подготовки передачи управления. Для достижения поставленной цели алгоритм
отодвигает эти инструкции disp от инструкций передачи управления и, соответственно,
занимает регистры передачи управления так, чтобы к моменту выполнения перехода
необходимый код уже находился в буфере инструкций.
В итоге возможна такая ситуация, что предварительная подкачку невозможно
применить для критических с точки зрения количества блокировок участков, поскольку
все регистры передачи управления оказываются заняты. Эта проблема решается
посредством исключения одного из регистров передачи управления из числа
доступных во время работы алгоритма распределения. Однако не во всех случаях
регистр передачи управления можно исключать. Для принятия подобного решения
необходимо убедиться, что в коде процедуры основное время исполнения занимают
достаточно длинные CCS, а имеющиеся инструкции передачи управления
маловероятны. Удаление регистра из распределения происходит, если выполняется
следующее неравенство:
CCS L Y 
 ρ,
(CCS )
где (CCS ) – сумма счетчиков (по профилю) широких команд, входящих во все CCS
процедуры; CCSLY  – сумма счетчиков (по профилю) широких команд, входящих во
все CCSL>Y процедуры; Y и  − параметры, которые подбираются с целью наиболее
эффективного применения предварительной подкачки. Согласно данной эвристике,
один из регистров передачи управления исключается из распределения в том случае,
если вес CCSL>Y в процедуре превысит . По результатам исследований
предварительная подкачка продемонстрировала наилучшую эффективность при
значениях Y и , равных 1024 байта и 0.8 соответственно.
На рис. 5 показаны результаты применения предварительной подкачки, а
именно, отношение времени исполнения задачи без использования предварительной
подкачки ко времени исполнения задачи с использованием предварительной подкачки
кода.
Исходя из данных, представленных на рис. 4, можно было бы ожидать, что
основной положительный эффект от предварительной подкачки кода проявится на
задачах 099.go, 129.compress, 130.li, 134.perl, 147.vortex, 186.crafty. Данное
предположение подтверждается для задач 099.go, 134.perl, 147.vortex, 186.crafty,
причины отсутствия существенного эффекта для остальных задач были выявлены при
дополнительном анализе. А именно, было установлено, что задачи 124.m88ksim,
129.compress, 130.li, 132.ijpeg на 90% помещаются в буфер инструкций. Процент
размещения в буфере инструкций рассчитывался следующим образом. Сначала все
широкие команды упорядочиваются по убыванию счетчика количества исполнений.
Далее счетчики суммируются до тех пор, пока суммарный размер широких команд не
превысит 64 килобайта (размер буфера инструкций). Полученная сумма по отношению
к счетчику всех широких команд и есть процент размещения задачи в буфере
инструкций. Как видно из таблицы на этих задачах подкачка кода не внесла
существенных изменений.
На задаче 126.gcc, несмотря на высокий процент блокировок и низкий процент
размещения в буфере инструкций прирост от подкачки кода незначителен. Это
обусловлено следующими факторами:
1. блокировки по ожиданию кода накладываются на большое количество
блокировок по ожиданию данных и при уменьшении блокировок по
ожиданию кода проявляются блокировки по ожиданию данных;
2. в задаче на участках применения предварительной подкачки кода ведется
активная работа с данными, подгружаемыми из оперативной памяти;
предварительная подкачка кода в силу особенностей аппаратуры довольно
часто вытесняет эти данные, вынуждая тем самым микропроцессор посылать
дополнительная запросы в оперативную память, в итоге увеличиваются
блокировки по ожиданию данных.
Программы с подкачкой кода на непрерывно исполняемых участках активнее
используют объемы кэша второго уровня, что позволяет говорить о его более
эффективном использовании. К сожалению, в то же время увеличиваются блокировки
по ожиданию данных на некоторых задачах, о чем свидетельствуют небольшие потери
производительности на задачах 124.m88ksim, 130.li, 132.ijpeg.
5. Выводы
Такие задачи, как 099.go, 134.perl, 147.vortex из пакета spec95 и 186.crafty из
пакета spec2000, содержащие весомое количество длинных непрерывно исполняемых
участков и обладающие малым процентом размещения в буфере инструкций,
доказывают эффективность применения описанного алгоритма.
К сожалению, во VLIW-архитектурах подкачке кода уделяют незначительное
внимание, делая акцент на подкачке данных. Это связано с ориентацией на работу с
циклами, что актуально для счетных задач. Однако, стоить отметить, что
эффективность подкачки кода для микропроцессора «Эльбрус» может возрасти с
увеличением объема кэша второго уровня. Помимо увеличения объемов кэша,
возможна и реализация специальной команды для подкачки данных, отнимающей
меньшие ресурсы, чем подготовка перехода.
Из представленных результатов видно, что предложенный метод
предварительной подкачки кода для микропроцессора «Эльбрус» позволяет повысить
производительность на определенном классе задач.
Список литературы
1. Smith A. J. Cache memories // ACM Computing Survey, Vol. 14, № 3, September 1982.
P.473-530.
2. Hennessy J., Patterson D. Computer Architecture: A Quantitative Approach. Morgan
Kauffman, 1990.
3. Bernstein D., Doron C., Freund A. Compiler Techniques for Data Prefetching on
PowerPC / Proc. of the International Conf. on Parallel Architectures and Compilation
Techniques, June 1995. P. 19-16.
4. Santhanam V., Gorhish E.H., Hsu W.C. Data Prefetching on the HP PA-8000 / Proc.
24th Annual International Symposium on Computer Architecture, Denver, CO, June 1997.
5. Silicon Graphics, Inc. MIPSpro Compiling and Performance Tuning Guide. Mountain
View, CA, 1997.
6. Intel Itanuim 2 Processor Reference Manual for Software Development and
Optimization. June 2002.
7. Porterfield A. K. Software Methods for Improvement of Cache Performance on
Supercomputer Applications. Ph. D. Thesis, Rice University, May 1989.
8. Nagle D., Uhlig R., Mudge T., Sechrest S. Optimal Allocation of On-chip Memory for
Multiple-API Operating Systems / Proc. of the 21st Annual International Symposium on
Computer Architecture, April 1994. P.358-369.
9. Torrellas J., Xia C., Daigle R. Optimizing Instruction Cache Performance for Operating
System Intensive Workloads / Proc. of the 1st International Symposium on HighPerformance Architecture, January 1995. P. 360-369.
10. Nagle D., Uhlig R., Mudge T., Sechrest S., Emere J. Instruction Fetching: Coping with
Code Bloat. Proc. of the 22th Annual International Symposium on Computer Architecture,
June 1995. P. 345-356.
11. Chen T.-F., Baer J.-L. Effective Hardware-Based Data Prefetching for High
Performance Processors // IEEE Transactions on Computers, Vol. 44, № 5, May 1995. P. 609623.
12. Zhang Y., Haga S., Barua R. Execution History Guided Instruction Prefetching / Proc.
of the 16th Annual International Conf. on Supercomputing, June 2002. P. 199-208.
13. Luk C.-K., Mowry T. Architectural and Compiler Support for Effective Instuction
Prefetch: A Cooperative Approach // ACM Transactions on Computer Systems, Vol. 19, № 1,
February 2001. P. 71-109.
14. Xia C., Torrellas J. Instruction Prefetching of Systems Codes with Layout Optimized for
Reduced Cache Misses / Proc. of the 23rd Annual International Symposium on Computer
Architecture, May 1996. P. 271-282.
15. Colwell R. P., Nix R. P., O’Donnel J. J., Papworth D. B., Rodman P. K. A VLIW
Architecture for a Trace Scheduling Compiler. Proc. of the 2nd International Conf. on
Architectural Support for Programming Languages and Operating Systems // SIGPLAN
Notices, Vol. 22, № 10. October 1987. P. 180-192.
16. Ellis J. R. Bulldog: A Compiler for VLIW Architectures. Cambridge: MIT Press, 1986.
17. Babayan B. E2K Technology and Implementation / Proc. of the 6th International
Conf. Euro-Par 2000 – Parallel Processing. Vol. 1900/2000, January 2000. P. 18-21.
18. Dieffendorf K. The Russians Are Coming. Supercomputer Maker Elbrus Seeks to Join
x86/IA-64 Melee. Microprocessor Report, Vol. 13, № 2. February 1999.
P. 1-7.
19. Standard Performance Evaluation Corporation, http://www.spec.org
20. Новиков С. В. Развитие методов глобального планирования для архитектур с явно
выраженной параллельностью: Дис. канд. тех. наук: 05.13.11. М.: ЗАО “МЦСТ”, 2005.
21. Галазин А. Б. Оптимизация участков кода с малым количеством исполнений /
Высокопроизводительные вычислительные системы и микропроцессоры: сборник
трудов ИМВС РАН. Вып. 9. М., 2006. С. 58-63.
22. Muchnick S. Advanced Compiler Design and Implementation. San Francisco, 1997.
Chapter 7.2.
25,00
До преобразования
20,35
После преобразования
20,00
13,63
15,00
10,00
8,57
8,69
8,77
8,16
7,87
4,50
5,00
5,76
2,46
0,67
0,56
15,15
2,32
1,68
0,64
0,73
0,59
0,00
ty
af
cr
6.
18
ex
rt
vo
7.
14
rl
pe
4.
13
g
pe
ij
2.
13
li
0.
ss
13
re
mp
co
9.
12
c
gc
6.
m
12
si
8k
m8
4.
12
go
9.
09
Рис. 1. Количество CCSL>256 до и после применения глобального планирования (в % от
общего числа CCS задачи).
1,20
1,00
0,96
0,93
0,95
0,90
0,88
0,94
0,86
0,81
0,76
0,80
0,60
0,40
0,20
0,00
18
14
c
6.
ra
y
ft
l
eg
x
te
er
jp
es
pr
or
p
4.
i
2.
v
7.
13
13
i
om
s
im
ks
cc
l
0.
c
9.
13
12
g
6.
o
88
g
9.
m
4.
12
12
09
Рис. 2. Изменение количества CCS в результате линеаризации графа.
1,60
1,40
1,34
1,30
1,25
1,13
1,20
1,04
1,03
1,00
1,00
1,22
1,01
0,80
0,60
0,40
0,20
0,00
18
14
c
6.
ra
y
ft
l
eg
x
te
er
jp
es
pr
or
p
4.
i
2.
v
7.
13
13
i
om
s
im
ks
cc
l
0.
c
9.
13
12
g
6.
o
88
g
9.
m
4.
12
12
09
Рис. 3. Изменение количества CCSL>256 в результате линеаризации графа.
25,00
22,20
19,32
20,00
18,09
15,00
12,21
11,60
10,54
8,73
10,00
7,08
6,70
5,00
0,00
18
14
c
6.
ra
y
ft
l
eg
x
te
er
jp
es
pr
or
p
4.
i
2.
v
7.
13
13
i
om
s
im
ks
cc
l
0.
c
9.
13
12
g
6.
o
88
g
9.
m
4.
12
12
09
Рис. 4. Количество CCSL>256 в задачах (в % от общего числа CCS задачи).
1,080
1,060
1,060
1,040
1,050
1,030
1,030
1,015
1,020
1,001
0,998
1,000
0,998
0,996
0,980
0,960
18
14
c
6.
ra
y
ft
l
eg
x
te
er
jp
es
pr
or
p
4.
i
2.
v
7.
13
13
i
om
s
im
ks
cc
l
0.
c
9.
13
12
g
6.
o
88
g
9.
m
4.
12
12
09
Рис. 5. Результаты применения предварительной подкачки кода.