Русский |  English
KM211

When everybody fails, we can do it!

We are commited to provide innovative,
reliable and original solutions
targeting 100% client satisfaction.

АСПЕКТЫ ОЦЕНКИ ЭФФЕКТИВНОСТИ ПРОЦЕССОРНЫХ АРХИТЕКТУР

Статья опубликована в журнале «Электронная техника. Серия 3. Микроэлектроника» Выпуск 2 (158)

 

 

 

Дмитрий Борисович Бычков, Святослав Юрьевич Дождев

 

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

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

К первой группе – общих тестов – относятся, например, давно и широко используемые тесты Whetstone (см. [1]) и Dhrystone ([2]) или более новый тест CoreMark ([3],[4]). Чтобы оценить применяемость в конкретной сфере, можно воспользоваться специфическими тестами типа DENBench ([5]), AutoBench ([6]) и т.п. Существуют даже исследования, помогающие потребителю выбрать наиболее подходящий тест (см., например, [7]).

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

Гораздо более сложная ситуация возникает, когда мы пытаемся объективно оценить какую-либо платформу с точки зрения плотности программного кода. Если упомянутые тесты производительности Dhrystone или CoreMark известны большинству заинтересованных пользователей, то кто может назвать общепринятые (и общепризнанные) тесты для оценки плотности кода?

Конечно, проводя оценку производительности посредством любого специализированного теста, параллельно можно сравнить и размеры получаемого кода для разных платформ. Но специализация теста, которая является плюсом при оценке специфической производительности, становится минусом при оценке плотности кода. Те или иные операции, типы данных или конструкции языка, характерные для конкретного специализированного теста, могут существенно исказить картину относительно использования той же платформы, но в другой предметной области. Значит, для объективного сравнения нужно перебрать несколько специализированных тестов из разных областей? Или ограничиться только синтетическими тестами типа CoreMark? Или выбрать несколько тестовых примеров случайным образом, как это было сделано в работе [8]?

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

Наконец, как быть разработчикам новых кристаллов – как позиционировать свою продукцию относительно уже имеющейся на рынке?

Какой тест или выборка тестов может считаться представительной, чтобы на ней можно было оценить по плотности кода связку «архитектура плюс компилятор»? Попробуем обосновать решение, принятое нами при оценке плотности кода для наших ядер KM32/KMX.

 

ДАННЫЕ ДЛЯ СРАВНЕНИЯ

 

По сути, требуется ответить на два вопроса: что сравнивать и что взять в качестве исходного тест-набора. В качестве ответа на первый вопрос представляется правильным подход, указанный в материале компании ARM (см. [9]). Там для оценки эффективности компилятора предлагается сравнивать либо чистый размер секции кода, либо общий «ROM footprint», исключая компонуемые библиотеки.

Возможно, для встроенных приложений логично было бы учитывать и размер библиотек, тем более что зачастую библиотеки компилируются теми же средствами, что и пользовательские программы. Но существуют и аргументы против этого. Во-первых, библиотеки от некоторых производителей могут быть написаны непосредственно на ассемблере или специально оптимизированы и значительно сокращены относительно стандартной библиотеки, как та же библиотека microlib ([10]). Это внесет перекос в сравнение конкурирующих платформ. Во-вторых, многие встроенные приложения вообще не нуждаются в поддержке файловой системы или не имеют стандартного ввода-вывода, работы со строками и т.д., другими словами, вообще не пользуются стандартными библиотечными функциями. Довольно подробно этот вопрос рассматривается в упомянутой работе [8] на примере функции printf.

В итоге, для целей нашего анализа мы приняли решение сравнивать полный «footprint» программы, попадающий в ROM кристалла и включающий в себя код, read-only данные и образ инициализируемых данных, но без учета библиотек.

 

TЕСТ-НАБОР

 

Мы исходили из того, что разработчикам компилятора с языка высокого уровня все равно приходится постоянно тестировать те или иные аспекты его работы. Одна из важнейших и самых критичных проверок – это проверка компилятора на соответствие стандарту языка. В силу объемности подобной проверки существует не так уж много публично доступных тестовых пакетов, посвященных этой теме. Те, кто работает в экосистеме gcc, пользуются имеющимися в его составе тестовыми пакетами (т.н. «testsuits», [11]). Из комплексных коммерческих продуктов отметим пакеты The Plum Hall Validation Suite for C ([12]) от одноименной американской компании и SuperTest compiler test and validation suite ([13]) от европейской компании ACE. Более полный список можно найти, например, на странице компании Texas Instruments, посвященной тестированию их собственных Си-компиляторов (см. [14]).

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

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

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

 

РЕАЛИЗАЦИЯ И РЕЗУЛЬТАТЫ

 

Мы попытались сравнить плотность программного кода для собственного ядра KM32/KMX с сопоставимым по вычислительной мощности ядром ARM Cortex-M3. Для ядра ARM мы по возможности брали самые последние из доступных версий компиляторов, кроме отдельно оговоренного случая. Вся компиляция проводилась с оптимизацией на размер кода. Платформы, участвующие в сравнении, сведены в таблицу:

 

Таблица 1. Версии и используемые опции сравниваемых компиляторов

Ядро

Разработчик компилятора

Компилятор и версия

Дата выхода

Опции компиляции

KM32

KM211 [15]

km32-gcc 4.6.0

 

-Os

KMX

kmx-gcc 4.6.0

 

-Os

Cortex-M3

Mentor Graphics [16]

arm-none-eabi-gcc 4.6.1

Декабрь 2011 г.

-mcpu=cortex-m3 -mthumb -Os

arm-none-eabi-gcc 4.7.2

Октябрь 2012 г.

-mcpu=cortex-m3 -mthumb -Os

Keil [17]

armcc 5.03

 

--cpu=cortex-m3 --thumb -Ospace

 

Как упоминалось выше, для тестирования всех платформ нами применялся пакет SuperTest [13], Rembrandt Release. Использовались следующие подмножества этого пакета: ·

  • тестовый набор на соответствие стандарту ANSI C (тест-набор «Breadth», тестовые поддиректории 2/,3/,4/) · 
  • тестовый набор на соответствие стандарту ISO/IEC 9899:1999 (тестовая поддиректория C99/) · 
  • тест вычислений с перебором всех возможных комбинаций различных типов операндов и операторов (тест-набор «Depth»)

 

В сравнении учитывались только те из тестов, которые были без ошибок скомпилированы для всех сравниваемых платформ, т.е. сравнение проведено на пересечении множеств успешно скомпилированных тестов. Общее количество тестов для сравнения составило 33534, что дало около 200 Мбайт объектного кода. Подсчитывался общий «footprint» объектных модулей без учета библиотек.

Результаты (суммарный размер объектных файлов в байтах) приводится на диаграмме.

 

Таблица 2. Сравнение результатов

Компилятор

Объём кода

armcc 5.03 (Keil)

244708664

arm-none-eabi-gcc 4.7.2 (Mentor)

194229727

arm-none-eabi-gcc 4.6.1 (Mentor)

219470062

km32-gcc 4.6.0 (KM211) 

221627286 

kmx-gcc 4.6.0 (KM211) 

208836368 

 


 

Рисунок 1. Сравнение результатов

code density

 

 

ЗАКЛЮЧЕНИЕ

 

1) Эффективность платформы KM32/KMX с точки зрения плотности программного кода находится на достаточно высоком уровне. Она выше по сравнению с результатами Keil для ARM: соотношение объемов кода равно 0.853 в пользу KMX при сравнении KMX/Keil, или 0.905 в пользу KM32 при сравнении KM32/Keil. Плотность кода для KMX выше даже по сравнению с gcc 4.6.1 от Mentor (соотношение объемов кода KMX/Mentor равно 0.952), и уступает только последней версии компилятора от Mentor (соотношение объемов кода KMX/Mentor равно 1.075 не в пользу KMX).

2) Переход от ядра KM32 к ядру KMX дает заметный выигрыш в плотности кода (соотношение объемов кода KMX/ KM32 равно 0.942 в пользу KMX). При этом выигрыш происходит за счет улучшения архитектуры ядра, т.к. «front-end» компилятора при переходе от KM32 к KMX не менялся.

3) Бросается в глаза значительное сокращение объема кода при переходе Mentor от версии 4.6 gcc к версии 4.7 (соотношение объемов кода для этих версий составляет 0.885). При этом основные изменения в компиляторе сосредоточены именно во «front-end», т.е. связаны с улучшениями в самом компиляторе. Таким образом, есть основания думать, что переход на новую версию gcc даст сходный положительный эффект и для компилятора KMX.

4) Неожиданно большим оказался объем кода, полученный на компиляторе от Keil по сравнению со средствами, основанными на gcc. По-видимому, с точки зрения плотности кода, основное преимущество при работе с Keil заключается в итоге не в эффективности самого компилятора, а в использовании Си-библиотеки, глубоко оптимизированной для встроенных приложений. Оптимизация библиотек для KMX (например, под конкретного пользователя или под применение) должна еще больше повысить эффективность платформы KM32/KMX с точки зрения плотности итогового программного кода.

5) При отсутствии специализированных средств типа [12] или [13], потенциальный пользователь может сравнить конкурирующие платформы с точки зрения плотности кода, воспользовавшись любыми доступными ему средствами, предназначенными для проверки компилятора на соответствие стандарту языка, например, [11].

6) Поскольку коммерческие тестовые пакеты требуют лицензирования, авторы планируют выложить в открытый доступ программные средства для сравнения плотности кода, основанные на использовании открытого программного обеспечения [18]. В качестве тест-наборов будут использованы тестовые средства, встроенные в сам компилятор gcc.

 

Список использованной литературы/Ссылки:

  1. Синтетический тест производительности Whetstone, Материал из Википедии, URL: http://en.wikipedia.org/wiki/Whetstone_(benchmark)
  2.  Синтетический тест производительности Dhrystone, Материал из Википедии, URL: http://en.wikipedia.org/wiki/Dhrystone 
  3. Синтетический тест производительности Coremark, Материал из Википедии, URL: http://en.wikipedia.org/wiki/CoreMark#CoreMark
  4.  Стартовая страница проекта Coremark, URL: http://www.coremark.org/
  5.  Специализированный набор тестов для задач мультимедиа DENBench, URL: http://eembc.org/benchmark/digital_entertainment_sl.php
  6.  Специализированный набор тестов для задач автомобильной и промышленной электроники, AutoBench, URL: http://eembc.org/benchmark/automotive_sl.php
  7.  Характеризация тестов EEMBC, URL: http://eembc.org/benchmark/characterization.pdf
  8.  Тест Си-компиляторов для ARM (RAISONANCE Application Note 52), PDF файл 
  9. Dhrystone Benchmarking for ARM Cortex Processor (ARM Application Note 273), URL: http://infocenter.arm.com/help/topic/com.arm.doc.dai0273a/DAI0273A_dhrystone_benchmarking.pdf
  10.  Microlib: библиотека для встроенных приложений, URL: http://www.keil.com/arm/microlib.asp 
  11.  Документация по компилятору gcc. Тестирование компилятора – Testsuits, URL: http://gcc.gnu.org/onlinedocs/gccint/Testsuites.html#Testsuites
  12.  Программный пакет «The Plum Hall Validation Suite for C», URL: http://www.plumhall.com/stec.html
  13.  Программный пакет «SuperTest compiler test and validation suite», URL:  http://www.ace.nl/compiler/supertest-compiler-test-and-validation-suite
  14.  Compiler validation, wiki-страница компании Texas Instruments, URL:  http://processors.wiki.ti.com/index.php/Compiler_Validation
  15.  Сайт компании КМ211, URL:  http://www.km211.com/
  16.  Проект SourceryCodeBench, страница загрузки, URL: http://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/evaluations/ 
  17. Средства компиляции компании Keil для процессоров ARM, URL: http://www.keil.com/arm/realview.asp#compiler
  18.  Страница загрузки Code Density Compare Tool, Дизайн Центр КМ211, URL: http://www.km211.com/ru/downloads