Введение в компиляторные оптимизации

Характеристики производительности встраиваемых приложений

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

• это маломощные устройства или устройства с батарейным питанием;
• они имеют ограниченный объем памяти;
• они нечасто обновляют приложения.

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

Оптимизация энергопотребления

Существуют две точки зрения, как уменьшать энергопотребление во время работы приложения:

• выполнение/разработка инструкций с низким энергопотреблением;
• как можно более быстрое выполнение инструкций и переход в режим ожидания.

Каждый из подходов имеет свои достоинства и недостатки. Далее кратко описан каждый из них.

Выполнение/разработка инструкций с низким энергопотреблением

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

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

Существуют также ситуации, когда система может иметь конфигурацию big.LITTLE. Более мощные процессоры используются только при увеличении потребности в вычислениях, в остальное время вычисления выполняются на маломощных процессорах. Если мы можем скомпилировать тяжелые для вычислений части кода для мощных процессоров (флаг -mtune), а остальные - для маломощных, мы можем воспользоваться этой возможностью. Эта стратегия потребует регулярного обновления флагов сборки в сочетании с оптимизацией под профиль (PGO).

Как можно более быстрое выполнение инструкций и переход в режим ожидания

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

Оптимизация размера двоичного файла

Мы уже обсуждали уменьшение двоичного размера приложения в предыдущем разделе ""Оптимизации компилятора для уменьшения размера кода"" .

Оптимизация приложений, которые не часто меняются

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

Справочные материалы

• Адитья Кумар - Оптимизация размера кода компилятора и методы для встраиваемых систем
• Адитья Кумар и Себастьян Поп - Анализ производительности и оптимизация стандартных библиотек C++
• Сообщество разработчиков Visual Studio - pragma optimize off работает не так, как ожидалось
• nm(1) - страница руководства Linux
• Инструментирующие функции GCC
• Нитин Кумар - Оптимизация с управлением по профилю (PGO) с использованием GCC на IBM AIX
• Адитья Кумар - Анализ и оптимизация производительности
• Винодха Рамасами, Пол Юань, Дехао Чен, Роберт Хундт - Feedback-Directed Optimizations in GCC with Estimated Edge Profiles from Hardware Event Sampling