Адаптация тестов оценки производительности

АДАПТАЦИЯ ТЕСТОВ ДЛЯ ОЦЕНКИ ПРОИЗВОДИТЕЛЬНОСТИ
64-РАЗРЯДНОГО УНИВЕРСАЛЬНОГО СУПЕРСКАЛЯРНОГО
МИКРОПРОЦЕССОРА
С.И. Аряшев, А.А. Краснюк, П.А. Чибисов
Научно-исследовательский институт системных исследований РАН,
krasnyuk@pochta.ru
Введение
Оценка производительности вычислительной системы (ВС) предназначена для предсказания
эффективности использования системы для решения некоторого класса задач, такие как мультимедиа,
моделирование физических и химических процессов, конструкторское моделирование,
экономические приложения и другие. Задачу этой оценки решают специальные программы-тесты,
которые производят измерения в некоторых единицах. Обычно тесты написаны на языках высокого
уровня, таких как C и Fortran, что позволяет сравнивать системы с различной архитектурой.
Понятие производительности вычислительной системы
В самом общем плане понятие производительности вычислительной системы включает в
себя следующие категории:
 Быстродействие (реактивность) – время получения ответа на запрос;
 Загрузка (использование) – качественная оценка использования ресурсов;
 Продуктивность (производительность) – количество обрабатываемой информации за
единицу времени. Продуктивность можно вычислить как произведение быстродействия на загрузку.
Хотя и существуют формулы для теоретического расчета производительности, на практике,
для таких сложных систем как микропроцессор, их не используют, так как много проще
непосредственно измерить ее специальными и универсальными средствами. Обычно под
производительностью имеют в виду продуктивность ВС, и, кроме того, выделяют два типа
производительности: пиковую и реальную.
Исторически первой определили так называемую пиковую производительность, равную
максимальному количеству выполняемых команд всеми имеющимися АЛУ при идеальных условиях.
Пиковая производительность достигается при выполнении микропроцессором бесконечной
последовательности не связанных между собой команд, которые не претендуют на одно устройство.
При этом подразумевается, что код программы и данные находятся в кэш-памяти. Ее легко
рассчитать теоретически, зная тактовую частоту и количество АЛУ, но реально система не может
находиться сколько-нибудь длительное время в таком состоянии.
Сравнение систем только по пиковой производительности не всегда приводит к адекватным
результатам, так как не учитывает функционального наполнения команд. Один и тот же результат
может быть получен разным количеством команд, например, команды выполняющие сложение и
умножение четырех чисел. Вместо трех команд выполняется одна, и, хотя значение пиковой
производительности получится меньшей, реальная производительность окажется выше. Реальная
производительность показывает производительность системы при решении конкретной задачи. Но
определить реальную производительность много сложнее пиковой, так как необходимо учитывать
множество факторов, которые могут оказывать очень сильное влияние на результат. Множество
тестов оценки производительности тому подтверждение – если один тест показывает высокий
уровень производительности некоторой системы, то это не значит, что другой тест покажет такой же
результат. Поэтому, для объективной оценки производительности используются пакеты тестов, а
значения результата прохождения теста зависит от области применения ВС.
Факторы, влияющие на производительность ВС
Современные микропроцессоры являются сложными системами, состоящими из многих
компонентов, и все они оказывают свое влияние на производительность. Основными из них являются
следующие факторы:
 Архитектура микропроцессора;
Набор команд микропроцессора определяет удобство и эффективность реализации
пользовательских задач на данном микропроцессоре.
 Разрядность микропроцессора;
При большей разрядности микропроцессора позволяет аппаратно выполнять операции над
числами с большей разрядностью.
 Количество АЛУ;
Процессоры, имеющие несколько АЛУ (целочисленных и вещественных) могут выполнять
вычисления сразу для нескольких команд. При этом устройство управления микропроцессора должно
263
выявлять зависимости между командами и выбирать команды, которые можно выполнять
параллельно.
 Наличие и производительность блока вещественной арифметики;
Аппаратная реализация операций над вещественными числами много эффективнее
программной. Это особенно актуально для научно-технических задач.
 Количество и размер регистров;
Чем больше регистров общего назначения, тем больше данных можно разместить в них и тем
меньше обращений требуется к оперативной памяти.
 Наличие и размер конвейера;
Это частный случай параллельности выполнения команд. При отсутствии задержек на
стадиях выполнения, позволяет получать результат каждый такт, хотя длительность выполнения
одной команды остается прежней.
 Наличие и размер кэш-памяти;
Обращения к оперативной памяти обычно занимают много времени, которое процессор
простаивает, ожидая данных или команд, тогда как наличие быстрой кэш-памяти, позволяет
сократить это время.
 Ширина окна исполнения.
Данный параметр показывает максимальное количество одновременно выполняемых команд
микропроцессора.
Можно выделить еще много других параметров микропроцессора, которые оказывают свое
влияние на его производительность. В том числе на производительность системы оказывает влияние
не только аппаратура микропроцессора, но и сама программа. Одну и ту же задачу можно решить
многими способами, и с разной эффективностью. При использовании языков высокого уровня на
значение производительности может оказывать очень сильное влияние компилятор. Оптимизация
кода позволяет сократить количество команд, требуемых для выполнения программы, собирает код, в
котором будет меньше зависимостей между командами, или код из команд, выполнение которых
требует меньшего времени. Существует множество способов оптимизации кода программы, которые
позволяют сократить время выполнения программы микропроцессором и вычислительной системой в
целом, тем самым, влияя на оценку производительности.
Классификация тестов оценки производительности
Тесты оценки производительности можно классифицировать по нескольким параметрам.
Например, по объекту тестирования: микропроцессор, отдельный его блок, или оперативная память,
вычислительная система в целом, сетевые подключения и так далее. В данной работе рассмотрены
только тесты оценки производительности микропроцессора.
Наиболее популярная классификация тестов приведена на рис.1. К первой группе относятся
так называемые тесты разработчика. Их создают компании-разработчики микропроцессоров. Такие
тесты ориентированы на некоторую серию микропроцессоров и позволяют оценить эффективность
принимаемых решений в пределах одной архитектуры, но для других архитектур эти тесты не
применимы.
Тесты оценки производительности
микропроцессора
Тесты разработчика
Универсальные тесты
Синтетические
тесты
Тесты, являющиеся
частью реальные задач
Рис. 1. Классификация тестов оценки производительности
Другая группа тестов – универсальные тесты оценки производительности микропроцессоров.
Эти тесты рассчитаны на широкий диапазон архитектур. Это достигается использованием языков
высокого уровня для создания таких тестов, что позволяет тестировать все архитектуры
универсальных микропроцессоров, при условии наличия компилятора языка. Среди них можно
выделить две группы тестов: синтетические и тесты, являющиеся частью реальной задачи. Первые
содержат смесь инструкций в пропорции, характерной для прикладных программ. Представителями
этой группы являются тесты Dhrystone, Whetstone, Flops. Вторая группа универсальных тестов
содержит части задач, являющихся типичными для некоторого типа приложений. Эти тесты на
264
сегодняшний день весьма многочисленны. Среди используемых задач можно выделить различные
действия над матрицами, преобразование Фурье, решение различных классических задач (задача о
Ханойской башне, вычисление ряда Фибоначчи, шахматные задачи и карточные игры), и этот список
продолжает расти вместе с расширением сферы применения вычислительной техники.
Практически все тесты имеют собственные единицы измерения производительности, хотя
иногда они и имеют одинаковое название. Очень часто приводят сравнение полученных результатов с
результатами, полученными на некоторой широко распространенной машиной, вводя таким образом
относительный рейтинг машин.
Вместе с развитием вычислительной техники и сферы ее применения, изменяются и тесты
оценки производительности. Новые тесты учитывают специфику приложений, развитие архитектуры
микропроцессоров, увеличение общего объема памяти.
Адаптация тестов оценки производительности
Существующие тесты оценки производительности предполагают запуск на готовой
вычислительной системе, но моделирование такой системы затруднительно, особенно на ранних
этапах разработки модели. Существующие тесты производительности предполагают запуск под
управлением операционной системы. На ранних этапах разработки модели микропроцессора не
всегда удается обеспечить запуск операционной системы из-за неполного функционального состава
системы. В тоже время, начать оценку производительности желательно на как можно более ранних
этапах. Действия, необходимые для адаптации теста для оценки производительности модели
микропроцессора, представлены на рис.2.
На раннем этапе разработки модели микропроцессора требуется обеспечить работу тестов на
модели без управления операционной системы. Рассмотрим, что для этого требуется.
Главная задача для любого теста оценки производительности корректно измерить время
работы. В имеющихся исходных текстах тестов оценки производительности
используются
системные функции получения текущего времени, зависимые от среды запуска теста (UNIX-системы,
MS C, Borland C, Turbo C и другие). Все они не годятся для самостоятельного запуска теста, так как
предполагают использование системных вызовов операционной системы. Как правило, в архитектуре
микропроцессора имеется регистр-счетчик, который инкрементирует свое значение каждый
выполненный такт. Также всегда известна предполагаемая частота работы целевого
микропроцессора. Зная содержимое регистра и тактовую частоту, можно вычислить время работы
тестового кода. Следовательно, процедура реализации теста может выглядеть следующим образом:
ассемблерная вставка считывания регистра-счетчика и деление полученного целого числа на
тактовую частоту в вещественном формате представления чисел. В главную программу
возвращаются оба числа – количество инструкций для определения рейтинга MIPS (Millions
Instruction Per Second) и второе для сравнения с известными результатами прохождения этого теста.
Следующие изменения связаны с отсутствием загруженной операционной системы. Как
следствие, в среде работы теста отсутствует файловая система и программное окружение теста.
Некоторые тесты предполагают задание параметров запуска из командной строки. Наиболее
простой способ решить эту проблему – задание этих параметров по умолчанию.
Многие тесты обращаются к файловой системе для загрузки (чтение файла) и сохранения
(запись) данных. Такие операции над файлами можно заменить операциями ввода/вывода на
терминал или полностью исключить. Для тестов оценки производительности важно не изменить
тестирующий цикл. Анализ имеющихся тестов показал, что операции работы с файлами находятся за
пределами тестирующего цикла и являются частью интерфейса теста. Таким образом, главным
критерием в выборе действия над этими операциями, является их информативность.
Предполагается, что все остальные функции, используемые в тестах, имеются в
подключаемых библиотеках, и нет необходимости в их создании. Для тестов, написанных на С,
существуют исходные тексты большинства библиотечных функций и можно скомпилировать
недостающие функции самостоятельно.
Для программ, запускаемых без операционной системы, характерна еще одна особенность –
завершение выполнения программы. Этот вопрос желательно также решить. В противном случае
возможно «зависание» системы моделирования, что нежелательно при автоматизированном запуске
тестов. Оптимальный способ – создание универсальных функций завершения работы модели и
включение их в состав программы.
Для запуска тестов под управлением операционной системы адаптации тестов практически
не требуется, так как большинство функций реализовано в системе. Остается только одна проблема –
объективная оценка времени работы тестирующего цикла. При оценке времени работы теста без
операционной системы используется системный регистр-счетчик, и, на первый взгляд, можно было
бы использовать его и при запуске системы под управлением операционной системы, но это может
привести к некорректным результатам. При запуске без операционной системы была необходимость
использовать свой вариант из-за отсутствия готовых решений, тогда как в состав всех тестов входит
своя функция определения времени, и ее желательно оставить.
265
Адаптация тестов оценки производительности
Тест запускается без ОС
Тест запускается под управлением ОС
1. Реализация функции определения
времени на основе предложенных в
тесте
2. Внесение изменений, исключающих работу с файловой системой
1. Выбор
времени
функции
определения
2. Синхронизация внесенных изменений
А) Работа с файловой системой
3. Внесение изменений, исключающих обращения к передаваемым
параметрам из командной строки
4. Внесение временных изменений,
связанных с ограничениями модели
5. Внесение временных изменений,
помогающих при отладке теста
Б) Режим работы теста
3. Внесение временных изменений,
связанных с ограничениями модели
4. Внесение временных изменений,
помогающих при отладке теста
Рис. 2. Адаптация тестов оценки производительности
Модель позволяет получить много больше информации о работе программы, нежели это
доступно программным способом. Для объективного сравнения результатов прохождения тестов на
модели без и под управлением операционной системы, необходимо синхронизировать изменения в
тексте тестов, в частности, относительно работы с файловой системой и режима работы теста. Но для
сравнения результата прохождения теста с опубликованными результатами коммерческих
производителей микропроцессоров необходимо использовать оригинальный текст теста.
При работе с моделью в процессе ее разработке можно столкнуться с еще одной трудностью некоторые функции микропроцессора могут быть еще не реализованы, например, может полностью
отсутствовать блок вещественной арифметики. Таким образом, возможно внесение временных
изменений в исходные тексты с целью исключения нереализованных функций. Если эти изменения не
принципиальны, то возможны модификации текста и в пределах тестирующего цикла, например, при
подсчете второстепенных результатов. Это может помочь отладить остальную часть теста и получить
предварительные результаты. В последующем, когда функциональность модели будет достаточной
для полного запуска теста, можно вернуть исключенные части кода.
Известно, что моделирование таких сложных объектов, как микропроцессор, занимает много
больше времени, нежели работа реального микропроцессора. Для повышения точности, в тестах
обычно организуют циклы и замеряют общее время выполнения (при этом, оно должно составить
хотя бы несколько секунд, т.к. точность результата тем выше, чем больше тестовых циклов
пройдено). Поэтому, на этапе отладки теста имеется возможность сократить число выполняемых
прохождений цикла, за счет чего существенно уменьшить расходуемые машинные ресурсы на
моделирование. Некоторые тесты учитывают количество прохождений теста при вычислении
результатов, кроме тестов, использующих в качестве характеристики производительности время
выполнения всей совокупности циклов. Обычно это тесты, направленные на решение некоторой
задачи. Понижение времени выполнения для таких тестов также возможно за счет уменьшения
коэффициента сложности задачи. Таким коэффициентом служит искомое число последовательности
Фибоначчи, количество блоков в задаче о ханойской башне и другие, специальные параметры,
целиком зависящие от задачи. Универсального решения в данном случае найти нельзя, но после
отладки необходимо восстановить этот параметр и произвести моделирование с исходным значением.
В противном случае, будет невозможно объективное сравнение с опубликованными результатами
выполнения этого теста.
266
Последовательность запуска тестов
Порядок моделирования теста для запуска без и под управлением операционной системы
различается. Общий алгоритм запуска теста без операционной системы представлен на рис.3, а под
управлением операционной системой на рис.4.
Начало
Начало
Внесение изменений в исходный
текст программы и условия
компиляции
Внесение изменений в исходный
текст программы и условия
компиляции
Компиляция и запуск теста на
образцовом эмуляторе
Подготовка системы к запуску
теста
Тест пройден?
НЕТ
ДА
Запуск теста на образцовом
эмуляторе и сохранение
состояния
Тест пройден?
Запуск теста на RTL-модели
НЕТ
ДА
Тест пройден?
НЕТ
Запуск теста на RTL-модели
ДА
НЕТ
Изменение
модели
Результаты
прохождения
идентичны?
Тест пройден?
ДА
ДА
Фиксирование полученных
результатов
Фиксирование полученных
результатов
Все случаи
промоделированы
НЕТ
НЕТ
Все случаи
промоделированы
НЕТ
ДА
ДА
Конец
Конец
Рис. 3. Алгоритм процесса моделирования
при
запуске
теста
без
управления
операционной системы (ОС)
Рис. 4. Алгоритм процесса моделирования
при запуске теста под управлением
операционной системы (ОС)
После внесения необходимых изменений в текст теста, необходимо собрать код
(компилировать тест). Во всех случаях необходимо указать уровень оптимизации и архитектуру. При
компиляции теста для запуска без операционной системы, после того, как код собран, необходимо
разместить сегменты кода в оперативной памяти таким образом, чтобы не нарушить адресацию
267
операндов и условных переходов, а также настроить режим работы микропроцессора. Если тест
запускается под управлением операционной системы, то все эти действия выполняются
планировщиком процессов, входящим в состав операционной системы.
При запуске теста без операционной системы сначала проводится моделирование на
образцовом эмуляторе микропроцессора, и, если тест пройден, производится запуск теста на RTLмодели. При возникновении ошибки в ходе выполнения теста на эмуляторе, необходимо установить и
устранить причину ошибки и повторить моделирование. Для отладки теста возможно использование
других средств моделирования, например, эмулятор пошаговой работы микропроцессора. После
успешного моделирования на обеих моделях, производится сравнение трасс инструкций теста, и если
результаты различны, то это говорит о том, что модель содержит ошибку, и говорить о корректности
результатов нельзя. После исправления ошибки надо повторить моделирование. Получив корректные
результаты, их фиксируют и переходят к следующему режиму запуска теста или с другими ключами
компиляции.
При запуске теста под управлением операционной системы возникают другие трудности. На
данном этапе с большой долей вероятности можно говорить, что система не содержит в своем составе
ошибок, и сохранение всей трассы инструкций теста не требуется. Но сам процесс моделирования
операции загрузки операционной системы занимает весьма продолжительное время. Ускорить
процесс моделирования можно, используя механизм сохранения и восстановления состояния
микропроцессора [1]. Таким образом, можно сократить как время моделирования, так и
задействованные машинные ресурсы.
Хотя сравнение результатов прохождения тестов с опубликованными будет корректно только
при условии соблюдения условий компиляции (уровень оптимизации), в процессе моделирования
может представлять интерес и компиляция теста с другими ключами. С помощью ключей можно
указывать архитектуру микропроцессора, совместимую с разрабатываемой, ключи оптимизации
могут переставлять инструкции в коде, и производить другие изменения кода, которые могут
способствовать нахождению каких-либо дефектов в модели микропроцессора.
Эффективность работы суперскалярного микропроцессора зависит в значительной степени от
качества формируемого кода программы, т.е. в коде не должно содержаться команд, не являющихся
необходимыми для реализации алгоритма программы; расположение команд в исполняемом коде
должно максимально загружать все необходимые ресурсы микропроцессора. Различные компиляторы
по-разному складывают данные и преобразуют функции в код. Для исследования степени влияния
работы компилятора на результаты тестов оценки производительности, тесты были скомпилированы
с использованием трех различных компиляторов. Полученные результаты говорят о том, что
компиляторы имеет ряд отличий в результирующем коде, то есть тесты, собранные ими, показывают
различную оценку производительности. Для всех трех компиляторов были также использованы
различные режимы работы, отличающиеся уровнями оптимизации и заданием различных целевых
архитектур (при условии совместимости с моделью). Использование более развитых целевых
архитектур, добавляет некоторые дополнительные команды, в том числе 64-разрядные, позволяющие
повысить качество кода. Как следствие, для выполнения теста требуется меньшее количество команд,
что оказывает влияние на полученные результаты. Очевидно, наибольший эффект на результаты
оказывает использование оптимизации. Даже использование оптимизации первого уровня (О1)
повышает оценку производительности в несколько раз. В отсутствие оптимизации компилятор
стремится минимизировать затраты на компиляцию и обеспечить наилучшие условия отладки.
В результате проделанной работы предложены рекомендации по адаптации тестов оценки
производительности микропроцессора. Данные рекомендации носят общий характер и могут быть
также полезны при адаптации любых программ, написанных на языках высокого уровня, для их
запуска на модели универсального микропроцессора.
ЛИТЕРАТУРА
Чибисов П.А., Николина Н.В. Функциональная верификация RTL-модели суперскалярных
микропроцессоров. Электроника, микро- и наноэлектроника. Сборник научных трудов. –
М.:МИФИ, 2004. - С. 213–216.
2. Hennessy J.L., Patterson D.A. Computer Architecture: A Quantitative Approach, 3rd ed., Morgan
Kaufmann Publishers, 2003. - 1072 p.
3. IEEE Standard for Binary Floating Point Arithmetic ANSI IEEE Std. 754–1985.
4. Корнеев В.В. Киселев А.В. Современные микропроцессоры 3-е изд., перераб. и доп., СПб.:БВХПеребург, 2003.
1.
268