Моделирование без моделирующего устройства

Авторы: Сергей Желтов и Станислав Братанов

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

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

Это позволяет понять важность оценки значимых характеристик при проектировании архитектуры до начала реальной работы над моделированием.

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

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

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

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

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

Анализатор языка ассемблера, являющийся ядром технологии, может быть настроен для перехвата любой инструкции (группы инструкций, конструкции ассемблера и т. п.), которые могут представлять интерес для имитационного модуля высокого уровня.

На рис. 1 представлен обзор процесса оснащения и общее представление о том, как работает технология.

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



Рис. 1. Обзор технологии

После того как файл ассемблера оснащен, он компилируется в файл объекта, а затем выполняется построение исполняемого модуля.

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

Как показано на рис. 1, во время выполнения запускается функции ответного вызова, которую мы задали ранее на этапе оснастки, и получает все необходимые параметры, описывающие моделируемую операцию (например, адрес, тип и размер операнда, тип доступа — для чтения или для записи). Функция ответного вызова имеет параметр непосредственного вызова модуля имитатора, выполнения вычислений, предшествующих моделированию, и сохранение необходимых параметров в виде файла для последующего анализа.

Результаты моделирования доступны в любое время при выполнении программы из используемого модуля имитации. Это обеспечивает динамический контроль над процессом моделирования.

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



Рис. 2. Добавление интерфейса пользователя к обычной процедуре сборки

Если вы выбирали компилятор, выберите в меню параметр Code Processor, установите флажок Use parser-passed compilation и выберите нужный инструментальный модуль.

Хотя на данный момент реализованы только два модуля имитации, авторы считают эти модули наиболее важными. Мы установили это, задав вопрос: что заставляет процессор работать медленнее? И установили «эффективные» средства уменьшения производительности процессора:

1. доступы к памяти после неудачных поисков в кэш-памяти;
2. ошибочно спрогнозированные ветвления, которые приводят к смещениям конвейера и остановам выполнения;
3. неправильная синхронизация или одновременное использование ресурсов несколькими потоками.

Итак, мы имеем следующее:

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

Более подробное описание каждого модуля приведено далее.



Рис. 3. Пример иерархии кэша

Текущий реализованный модуль имитации кэша может поддерживать произвольно выбранную конфигурацию кэша/памяти.

Он также вычисляет:

1. трафик в каждом направлении для кэша (операции чтения/записи);
2. успешный и неудачный доступ к строкам кэша;
3. информацию о разделенных и несогласованных операциях.

Для того чтобы поддерживать сложные кэш-системы в многопроцессорных компьютерах, в качестве объекта имитации введена шина:

1. связи между кэшами;
2. связи между ядрами в многоядерных архитектурах;
3. связи между разными модулями процессора;
4. трафик в каждом направлении для объекта шины.

Модуль имитации кэша поддерживает поточную обработку и поддерживает когерентность кэша при имитации многоядерных архитектур.

Пример системы кэша приведен на рис. 3.

В качестве примера программирования см. пример кода.

Модуль прогнозирования ветвления может имитировать разные схемы и алгоритмы прогнозирования ветвления.

Пока были реализованы два алгоритма:

1. статический BTFNT — ветвление назад прогнозируется как Taken, Forward as Not Taken;
2. динамический SPD — Simple Pattern Detection.

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

Последний из упомянутых методов предусматривает запоминание истории совершенных и не совершенных ветвлений и применение этих данных для прогнозирования следующего ветвления.

Модуль прогнозирования ветвлений обеспечивает для вызывающего оператора следующие данные:

1. количество спрогнозированных и ошибочно спрогнозированных ветвлений;
2. количество условных и безусловных ветвлений;
3. количество ветвлений вперед и назад;
4. подробные статистические данные прогнозирования ветвлений для каждого модуля и функции.

Для получения дополнительных сведений по применению см. пример кода.

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

Преимущества архитектурного имитатора:

• не нужно собирать аппаратную систему;
• точность результатов;
• имитация всей среды выполнения.

Недостатки:

• Часто приходится переносить исследуемое приложение в новую архитектуру.
• Иногда имитаторы накладывают на приложения свои ограничения, например ограниченный объем доступной памяти, операций ввода-вывода и т. п.
• Обычно, кроме имитатора, тратится много времени и ресурсов на разработку полного набора служебных программ (по крайней мере, компилятор + имитатор).

Преимущества технологии обработчика кода Code Processor:

• использование имеющихся компиляторов и ассемблеров в текущих архитектурах;
• быстрое моделирование процесса;
• ориентация на приложения;
• приложение анализируется без дополнительных ограничений (таких как ввод-вывод, память и т. п.)
• расширяемая конструкция — могут независимо друг от друга добавляться новые инструкции или наборы инструкций, новые реестры и модули имитации типов реестров, а также модули для имитации энергопотребления, использования шины и любых других характеристик системы.

Цель нашего анализа заключается в поиске и приближении к таким параметрам архитектуры, которые позволили бы компьютерной системе наиболее эффективным способом кодировать MPEG-2 HDTV-видео.

Для своих экспериментов мы выбрали следующее приложение:

видеокодер MPEG-2, разрешение HDTV (1920x1088), 1-секундная длительность, 30 кадров, с применением алгоритма Logarithmic Motion Estimation.

Во время эксперимента были оценены следующие параметры архитектуры:

параметры иерархии кэша:

• количество уровней кэша (L1 + L2);
• ассоциативность каждого кэша (от 4 до 32);
• размер (от 1 Кб до 32 Мб);
• размер строки кэша (64 байта).

Файл реестра:

• количество реестров (16, 32, 64);
• длина реестров (8, 16, 32 байта).

Модуль прогнозирования ветвления:

• процент прогнозирования ветвления для разных модулей кодировщика.

Использование кэша сокращает трафик, идущий от процессора к памяти.

На рис. 4 показаны два плоских региона в диаграмме трафика памяти. Они соответствуют эффективному размеру кэшей L1 и L2. Выбор любого значения размера кэша в пределах 64 Кб - 4 Мб и 32 Мб -128 Мб обеспечивает стабильный и прогнозируемый уровень трафика.



Рис. 4. Имитация параметров системы кэша

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



Рис. 5. Имитация параметров файла реестра

Как показано на рис. 5, большее количество реестров предпочтительнее для кодировщика MPEG, в то время как увеличение размера реестра не обязательно приводит к положительным результатам.

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

На рис. 6 показан процент спрогнозированных ветвлений. Статический алгоритм прогнозирования работает хорошо, приблизительно 10% остаются для последующей доработки. Это можно объяснить тем, что оптимизация выполнялась компилятором, который генерирует инструкцию ветвления в соответствии со статическим методов прогнозирования.



Рис. 6. Имитация результатов прогнозирования ветвления

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

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

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

Результаты предварительного анализа имеют большое значение для принятия окончательных проектных решений.

Сергей Желтов – руководитель проекта подразделения Microprocessor Research в Intel Labs. В числе объектов его исследовательской работы: сжатие и обработка данных мультимедиа, программные и платформенные архитектуры, обработка сигналов, спектры высоких порядков. Он окончил факультет радиофизики Нижегородского государственного университета и там же получил степень магистра в области теоретической и математической физики.

Станислав Братанов – разработчик программного обеспечения отделения Microprocessor Research в Intel Labs. В число его объектов его исследовательской работы входят многопроцессорные платформы ПО, среды операционных систем и кодирование данных мультимедиа, зависящих от платформы. Он окончил Нижегородский государственный университет в России.

1. http://www.sics.se/simics/publications.html
2. http://www.virtutech.com/
3. Й. Марате (J. Marathe) и др. Detailed Cache Coherence Characterization for OpenMP Benchmarks. (Подробная характеристика синхронизации кэшей для тестов OpenMP).
   По материалам ICS'04, 26 июня – 1 июля 2004 г.
4. М. Розенблюм (M. Rosenblum) и др. Using the SimOS Machine Simulator to Study Complex Computer Systems. (Использование машинного моделирования SimOS для изучения сложных вычислительных систем).
   ACM Transactions on Modeling and Computer Simulation (Транзакции ACM в моделировании и компьютерной имитации), Ч. 7, № 1, январь 1997, с. 78–103.
5. Л. ДеРоз (L. DeRose) и др.. SIGMA: A Simulator Infrastructure to Guide Memory Analysis (Инфраструктура устройства моделирования для проведения анализа памяти).