Работа выполнена в МФТИ при финансовой поддержке
Минобрнауки РФ (договор № 02.G25.31.0054).
Вопрос энергоэффективности все чаще становится предметом интереса инженеров, разрабатывающих программные продукты для платформы Intel. В этой области “преждевременные оптимизации” – дело особенно неблагодарное, поэтому за последние годы был создан ряд измерительных инструментов разной степени применимости. Эта статья расскажет о средствах энергопрофилирования, доступных на трех платформах (Windows, Linux, Mac), и даст некоторые советы по оптимизации кросс-платформенного приложения.
Причина, по которой этот вопрос актуализируется, прозрачна: экспансия ARM-процессоров в области мобильных устройств все чаще наводит на мысль о создании на этой платформе “Green-datacenters” [2][3], обещающих снизить существенные расходы на электроэнергию [1]. Поэтому для жизнеспособности решений на платформе Intel необходимо уделять внимание энергоэффективности. Это касается как прикладных задач, так и облачных решений, где вопрос размещения виртуальных машин включает в том числе и вопрос оптимизации энергопотребления. Далее мы рассмотрим структуру энергопотребления на архитектуре x86-64, определим, каким образом можно снизить этот показатель и как зафиксировать изменения при помощи профилировщика. Все данные для этой публикации получены на основе исследования, проводимого в Новосибирском Государственном Университете и МФТИ.
Энергопотребление платформы можно структурировать, разделив его на две части:
Динамическая часть энергопотребления, в свою очередь, складывается из потребления энергии процессором, памятью и устройствами, а также затрат на их взаимодействие. В данной статье мы в первую очередь сконцентрируемся на вопросах, связанных с замерами энергоэффективности использования CPU, но не оставим в стороне и другие устройства.
Чтобы исследовать этот вопрос в полной мере, в первую очередь стоит обратиться к спецификации стандарта ACPI [6], регламентирующего интерфейс регулирования энергопотребления операционной системой. Он объединяет ряд методик по снижению энергозатрат, опирающихся на достаточно очевидную идею: для устройства должен быть реализован набор состояний с пониженными запросами по энергии, но с урезанной в той или иной степени функциональностью. В случае, когда полная функциональность не востребована, есть резон в эти состояния переходить.
Важно осознавать, что переключение между состояниями не происходит мгновенно [7][16]. Переходы в более глубокие состояния сна происходят ступенчато и со временем, чтобы в случае необходимости максимально быстро вернуться в рабочее состояние. Принимая во внимание эти факты, можно уловить основную идею большинства методов энергосбережения: группировать обращения к устройству для увеличения длительности непрерывных интервалов простоя, чтобы устройство могло больше времени провести в наиболее глубоком состоянии сна.
Для CPU есть два основных набора состояний, позволяющих регулировать энергопотребление:
Для любознательного системного разработчика может оказаться интересной разница между двумя упомянутыми методами остановки работы CPU. HLT останавливает процессор до первого пришедшего прерывания. Связка MONITOR/MWAIT позволяет реализовать более интеллектуальный сценарий: при помощи MONITOR устанавливается некий адрес памяти, за которым будет происходить наблюдение, а после вызова MWAIT процессор уснет, пока не будет произведена запись в указанную область памяти. Это позволяет избавиться от busy-waiting в случае реализации примитивов синхронизации на уровне ядра ОС.
Помимо того, процессоры Intel содержат в себе набор эвристических алгоритмов управления энергопотреблением, и у разработчика есть возможность повлиять на их работу записью в MSR IA32_ENERGY_PERF_BIAS. Предполагается существование 16 уровней производительности (0 –максимальная производительность, 15 – максимальное энергопотребление/минимальная производительность).
Стоит отметить, что, хотя политика энергопотребления зачастую реализуется разработчиками ОС, понимание принципов позволит избежать сомнительных с точки зрения энергопотребления решений и в прикладной разработке.
Теперь самое время рассмотреть аппаратные инструменты энергопрофилирования, так как без них любая попытка оптимизации расходов энергии будет излишне самонадеянной.
С аппаратными средствами измерения абсолютных показателей потребления энергии у процессоров Intel долгое время была проблема: их не было. Вернее говоря, такие средства были реализованы как отдельные устройства, подключаемые к материнской плате (или, например, как Watts Up, через USB [19]), что достаточно неудобно, а порой почти нереализуемо (например, если нет физического доступа к машине).
Но уже процессоры Pentium содержали в себе модуль измерения производительности (Performance Monitoring Unit), который давал возможность собирать статистику по количеству аппаратных событий, происходящих в процессоре (например, количество исполненных инструкций, промахов кешей и т.д.). На базе этой статистики долгое время и производились оценки энергопотребления. Происходило это следующим образом: строилось некоторое предположение о корреляции между измеряемыми метриками и энергопотреблением системы (энергетическая модель), и далее, когда профайлер с заложенной моделью попадал на целевую машину, запускался процесс калибровки, связывающий оригинальные метрики и реальное энергопотребление. Далее по полученным коэффециентам можно оценивать энергопотребление.
Нетрудно догадаться, что такой подход не может гарантировать безошибочный результат, и поэтому в архитектуру Sandy Bridge был заложен RAPL интерфейс (Running Average Power Limit). После этого через набор msr’ов стало возможно получить информацию о количестве энергии, потребленной системой с момента запуска. Естественно, после этого обсуждать профилировщики, работающие на базе счетчиков производительности, кажется бессмысленным, но это не совсем так, ведь встретить машину, не оснащенную процессором на архитектуре Sandy Bridge и старше, все еще очень несложно, и RAPL позволяет оценивать только энергопотребление CPU, чего в некоторых случаях может быть недостаточно.
В данной части мы рассмотрим некоторые существующие утилиты измерения энергопотребления, обозначив их сильные и слабые стороны.
В первую очередь рассмотрим доступные разработчику инструменты, использующие метрики производительности, на базе которых строится оценка затраченной энергии:
PowerTop[10] (Linux) – эта утилита предоставляет информацию по энергопотреблению процессов системы в режиме реального времени. В своих выводах опирается на энергетическую модель, учитывающую потребление CPU, Network-devices, GPU и HDD [11]. Вносит overhead порядка 3%, что соответствует среднему значению для профилировщиков производительности. Среди безусловных плюсов стоит отметить то, что эта утилита сможет работать на большинстве существующих CPU от Intel (начиная с Core 2 Duo). Помимо того, инструмент предоставляет простой доступ к ряду параметров управления энергопотреблением системы, а также показывает, какие компоненты наиболее проблемные и приводит конкретные предложения по настройке с целью уменьшения потребления энергии. Примерами таких рекомендаций могут служить - включение энергосбережения Wi-Fi, перевод AC97 в режим энергосбережения, выключение звука, включение режима энергосбережения PCI Express и SATA-устройств, выключение опроса CDROM с помощью HAL, включение экономии энергии в настройках звукового чипа HDA и т.д. Также PowerTop может посоветовать изменения некоторых конфигураций ядра, например - dirty ratio, dirty background ratio, sched_mc_power_savings и т.п. Но стоит понимать, что утилита может выдавать статистику только по процессам, что значит, что профилирование конкретного приложения при помощи PowerTop является нетривиальной задачей, так как нет никакой привязки полученной статистики к исходному коду. В качестве источники данных PowerTop полагается на данные от PMU, которые по некоторым коэффициентам ставит в соответствие потребляемой электроэнергии.
Joulemeter[14] (Windows) – профилировщик, использующий, как и PowerTop, метрики производительности для оценки затраченной энергии [15]. Учитывает затраты CPU, HDD, GPU, сетевых устройств и экрана. Так же, как и PowerTop, не дает возможности связывать статистику с исходным кодом приложения, хотя и является удобным инструментом для анализа энергопотребления системы в целом. Так же как и PowerTop, Joulemeter полагается на статистику от PMU
Далее рассмотрим утилиты, которые помимо метрик производительности используют RAPL-интерфейс (прямые измерения энергопотребления CPU).
Intel Power Gadget [12] (Linux, Windows, OS X) - профилировщик, предоставляющий статистику по энергопотреблению выбранного пользователем приложения на машинах с CPU на базе Sandy Bridge и новее. Предоставляет также Power Gadget API, позволяющий пользовательским приложениям получать метрики энергопотребления. Так же, как и PowerTop, не может связывать статистику с исходным кодом.
Intel VTune Amplifier 2013 Update 13 [13] (Linux, Windows) – многофункциональный профилировщик производительности, позволяющий также измерять энергопотребление. Может связывать собранную статистику с исходным кодом, собирать стек вызовов и визуализировать полученную информацию. В режиме Advanced Hotspots + collection stack + estimate call counts также дает информацию по количеству потребленной энергии (метрики: Energy Core, Energy GFX, Energy Package). Позволяет получить статистику с точностью до инструкции, что дает очень широкие возможности по анализу для дальнейшей оптимизации.
Отдельно стоит отметить набор утилит для OS X Maverics, которые не предоставляют абсолютных значений затраченной энергии, но зато выдают ряд очень полезных агрегированных метрик, характеризующих энергопотребление системы.
Activity Monitor [17] (OS X) – монитор производительности, выдающий помимо прочего метрику, характеризующую энергоэффективность работающих приложений. Не дает очень детальной статистики, но позволяет оценить, есть ли смысл подключать более информативные инструменты для получения развернутой статистики.
XCode 5 [18] (OS X). В состав IDE от Apple был включен мощный инструментарий по анализу энергопотребления приложения. Он предоставляет агрегированные метрики, которые могут оказаться даже более информативными, чем абсолютные значения потребления энергии. Среди них можно выделить WakesPerSecond – количество “пробуждений” CPU в связи с активностью приложения (например, из-за таймеров и ряда других событий). В дополнение к этой метрике данный инструмент выстраивает CPU-usage трассу, на которой выделен CPU Wake Overhead. Такие трассы строятся отдельно для каждого из потоков, что упрощает анализ приложения. В отличие от Intel VTune Amplifier, инструмент от Apple не связывает напрямую измеряемые метрики и код приложения. Но, имея на руках информацию о проблемной тенденции, в большинстве случаев можно детализировать информацию при помощи других инструментов (например, причину частых пробуждений можно искать при помощи утилиты timerfires, а неоправданно высокий уровень утилизации CPU – профилировщиком Instruments).
Таким образом, мы видим, что для задачи анализа энергопотребления на любой ОС найдется ряд инструментов, предоставляющих различную степень детализации
|
Профили-ровщик |
ОС |
Модели процессора |
Измерение CPU Energy Usage |
Измерение Devices Energy Usage |
Привязка к исходному коду |
|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Имея на руках описанный арсенал инструментов профилирования и представление о предоставляемых оборудованием средствах уменьшения энергопотребления, можно заняться оптимизацией приложения. Среди основных методик улучшения профиля энергопотребления выделим основные:
Теперь коротко рассмотрим пример, иллюстрирующий часть методов оптимизации.
Предположим, что перед нами стоит тестовая задача: написать приложение, рассчитывающее числа Фибоначчи, и записывающее их в файл в CSV-формате. Для начала напишем “наивную” реализацию:
int main()
{
int cur0 = 1; cur1 = 1;
for( int i = 0; i < VALUES_TO_COUNT; ++i )
fprintf( file, “%d,”, count_fibo_and_store( &cur0, &cur1 );
return 0;
} |
С точки зрения оптимизации производительности напрашивается очевидное решение: записывать числа в файл не по одному, а блоками.
int main()
{
int cur0 = 1; cur1 = 1;
char* pBuffer = (char*)malloc( BUFFER_SIZE );
for( int i = 0; i < VALUES_TO_COUNT; ++i )
{
count_fibo_add_to_block( &cur0, &cur1, pBuffer );
if( (i % BLOCK_SIZE) == 0 )
write_block_to_file_and_erase( pBuffer );
}
return 0;
} |
Для валидации изменений (превратив псевдокод в работающий) воспользуемся профилировщиком Intel VTune Amplifier 2013 Update 13 на машине с Windows 8 и процессором Intel Core i5 на микроархитектуре Ivy Bridge.
Полученные результаты при последовательном вычислении 500 тысяч чисел Фибоначчи:
|
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Как видно из результатов, мы ускорили приложение почти в два раза, и тем самым добились заметного снижения уровня энергопотребления. Так что оптимизация производительности, как правило, очень благоприятна и в контексте разговора о энергопортеблении.
Но здесь можно обратить внимание на тот факт, что число тактов активной работы уменьшилось на 37% и число исполненных инструкций на 26%, а потребление энергии сократилось на 44%, т.е возможно наше улучшение связано не только с уменьшением времени активной работы процессора, но и с тем фактом, что мы уменьшили частоту обращений к диску. Для проверки этого тезиса изменим схему работы приложения: теперь программа будет не высчитывать 500 тысяч чисел Фиббоначи, а будет заниматься этим непрерывно в течение определенного интервала времени (выставим 4 секунды). Сделав эти изменения, снова произведем измерения.
|
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
И мы обнаруживаем следующее: несмотря на то, что оптимизированная версия исполнялась даже дольше (более того: исполнила на 40% больше инструкций полезной работы), количество потребленной энергии все равно ниже, чем в “наивной” реализации, что иллюстрирует тот факт, что отказ от частых обращений к устройствам увеличивает не только производительность, но и само по себе дает хороший вклад в энергоэффективность приложения.
Итак, мы рассмотрели основные методы снижения энергопотребления на платформе x86, а также инструменты профилирования и ряд техник повышения энергоэффективности. Мы надеемся, что данный анализ поможет широкому спектру специалистов – от производителей облачных решений, задумавших реализовать DPM, и администраторов до прикладных разработчиков. Уже сейчас прикладные разработчики под OS X поставлены в условия, когда вопросы энергопотребления пользовательских приложений стали и их проблемой, а не только вопросом компетенции разработчиков ОС [16] [17]. Такой подход позволил заметно увеличить срок работы от батареи устройств от Apple, и, очень вероятно, что в скором времени подобная практика станет нормой и для других платформ. Поэтому умение создавать энергоэффективные приложения сложно недооценить, и надеемся, что данная статья поможет вам в этом.
Версия для печати