Оптимизация энергопотребления приложений под Windows 8*

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

Для мобильных платформ одним из важнейших показателей является возможная длительность работы системы от аккумулятора. По мере перехода на новое оборудование (особенно это касается ультрабуков), все более важную роль в энергоэффективности системы начинает играть ПО: приложения в режиме ожидания должны потреблять как можно меньше энергии. Одно недостаточно оптимизированное приложение может свести на нет все преимущества всего остального программного обеспечения, спроектированного c учетом энергоэффективности. Например, если ОЕМ-производитель поставляет потребительские ПК всего с одним приложением, которое нерационально расходует энергию, то от этого пострадает вся система, поскольку вся система будет меньше времени работать от аккумулятора.

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

  • Аппаратное обеспечение:
    • CPU: мобильный процессор Intel© Core™ i7 второго поколения
    • Память: 4 ГБ DDR3 с пониженным расходом электроэнергии
    • Накопитель: 160 GB Intel® SSD
    • Адаптер беспроводной сети Intel® Wi-Fi*
    • Звуковой адаптер Realtek Audio
    • Экран высокой четкости (1080р)
  • Программное обеспечение:
    • Операционная система Microsoft Windows 8, в том числе:
      • Драйвер адаптера беспроводной сети Intel® Wi-Fi
      • Драйвер видеоадаптера сети Intel® HD
      • Драйвер набора микросхем Intel®


Рисунок 1. Влияние приложений на длительность работы от аккумулятора при «чистой» установке Windows в режиме ожидания.

Приложение находится в режиме ожидания, когда оно неактивно. Например, веб-браузер неактивен, когда в него загружена статическая веб-страница, не требующая действий пользователя. На рис. 1 показаны результаты влияния этих приложений на длительность работы системы от аккумулятора (каждое приложение запускалось по отдельности). Например, приложение «Браузер 4» сокращает длительность работы системы от аккумулятора приблизительно на 200 минут (в режиме ожидания, без каких-либо действий пользователя в течение по крайней мере 30 минут), а приложение «Чат 3» сокращает длительность работы системы от аккумулятора примерно на 180 минут, если просто это приложение просто запущено в фоновом режиме. При одновременном запуске нескольких таких приложений эффект нарастает соответственно.

На рис. 2 показано сравнение Windows без установленных приложений и Windows, в которой открыты и запущены в фоновом режиме все приложения, использованные на рис. 1. Если принять длительность работы системы с чистой Windows за 100%, то выполнение приложений в фоновом режиме приведет к сокращению времени работы от аккумулятора на 38,2%. Это крайне существенный эффект, особенно если учесть, что приложения, по сути, бездействуют. ОЕМ-производители, предлагающие готовые решения, должны пересмотреть свои программные продукты так, чтобы они не влияли на длительность работы ПК от аккумуляторов.


Рисунок 2. Сравнение времени работы от аккумулятора.


Таблица 1. Перечень желаемых показателей для разработки программного обеспечения с пониженным потреблением электроэнергии.



Разработчики программ должны учитывать, сколько электроэнергии потребляют их программы в режиме ожидания. В таблице 1 приведены желаемые показатели оптимального потребления электроэнергии приложениями для наибольшей экономии. Показано предполагаемое влияние работы программ на длительность работы системы от аккумулятора. Например, если система оснащена аккумулятором емкостью 33 Вт-ч, а мощность системы в режиме простоя - 3 Вт, то можно предположить, что длительность работы системы от аккумулятора составит 11 часов. Если повысить расход всего на 2% по сравнению с базовым (т.е. повышение на 60 милливатт), то время работы системы от аккумулятора снизится на 13 минут. Повышение расхода на 5% приведет к тому, что система будет работать от аккумулятора примерно на полчаса меньше. Чем ниже базовый уровень потребления, тем большее значение имеет влияние приложений.

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

 

Battery Life Analyzer (BLA)

Battery Life Analyzer (BLA) - это очень мощное средства анализа энергоэффективности. Эта программа была разработана компанией Intel для определения проблем, влияющих на длительность работы от аккумулятора. BLA помогает выявлять широкий набор проблем при анализе программ, в том числе:

  • Использование ресурсов CPU
  • Изменения периодичности работы таймера ОС
  • Частые изменения С-состояния
  • Избыточные действия ISR/DPC
  • Обновления вертикальной развертки графического адаптера


Пользовательский интерфейс программы Battery Life Analyzer

Пользовательский интерфейс BLA содержит ряд модулей анализа оборудования и программ (см. рис. 3).


Рисунок 3. Скриншот программыLife Analyzer program

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

  1. Выберите модуль.
  2. Настройте параметры модуля, например, пороги срабатывания предупреждений.
  3. Запустите запись данных анализа.
  4. Остановите запись.
  5. Сохраните результаты с помощью меню «Файл».

Также можно собирать данные BLA из командной строки, как показано на рис. 4.


Рисунок 4. Работа с Battery Life Analyzer из командной строки.


Интерфейс командной строки BLA позволяет с легкостью интегрировать эту программу в автоматизированный набор средств тестирования. Можно выполнять команды по одной или запускать несколько модулей последовательно, а затем сохранить результаты. Для получения подробных сведений об использовании BLA из командной строки используйте команду «BLA.exe –h».

Можно собирать данные о С-состоянии, чтобы узнать, потребляет ли приложение электроэнергию, будучи в состоянии ожидания. Полученные результаты можно сравнить с ожидаемыми в Таблице 2.


Таблица 2. С-состояния: описания и причины.

В таблице 2 показаны приложения в состоянии ожидания. Они должны превысить 95% в наиболее глубоком С-состоянии, чтобы в состоянии ожидания расход электроэнергии увеличивался только на 2%. Если результат ниже 95%, это может повлечь интенсивный расход энергии. В таблице также показано влияние на другие С-состояния и их причины. Например, приложение осуществляет операции ввода-вывода через подключение к Интернету, устройства USB или путем записи данных в журнал. Разработчики должны правильно проектировать состояния резидентности своих приложений.

Мы выбрали приложение для воспроизведения мультимедиа (из списка приложений, приведенного на рис. 1) для оптимизации с целью наибольшей экономии электроэнергии. Этот раздел мы разделили на 2 части согласно двум использованным нами средствам анализа:

- BLA

- Windows Performance Analyzer

Мы исследовали приложение с помощью BLA в течение 120 секунд. На рис. 5 показан результат влияния видеопроигрывателя в режиме ожидания на С-состояние. Когда приложение открыто и находится в режиме ожидания (т.е. не воспроизводит фильмы или музыку), видно существенное снижение резидентности пакета С7. Причиной этого является повышение резидентности пакетов С0-С1, С2 и С6. Это приложение даже во время ожидания образует нагрузку на CPU и сеть, из-за чего возросла резидентность пакетов С0 и С2.


Рисунок 5. Резидентность С-состояний приложения для воспроизведения мультимедиа.


Чтобы подробнее изучить причины повышения резидентности пакетов C0 и C2, мы использовали инструменты BLA. В таблице 3 показано количество вызовов в секунду при работе приложения в режиме ожидания. Процесс hal.dll, связанный с работой таймера ОС, показал существенное увеличение количества вызовов. Причина - сокращение периода обновления до 1 мс (т.е. 1000 вызовов в секунду) по сравнению с используемым в ОС по умолчанию значением в 15,6 мс (64 вызова в секунду). Из-за этого изменения периодичности обращений к таймеру длительность работы системы от аккумулятора снижается на 20%.


Таблица 3. Battery Life Analyzer - анализ программного обеспечения

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

 

Анализ приложения для воспроизведения видео с помощью Windows Performance Analyzer

Чтобы оценить влияние отдельных вызовов API на расход электроэнергии, мы использовали средство Windows Performance Analyzer (WPA), входящее в состав пакета Windows Assessment Development Kit.

Мы провели анализ приложения в состоянии ожидания с помощью модуля Windows Performance Recorder (WPR), входящего в состав WPA. Мы проводили общесистемный анализ информации в течение 180 секунд, а также включили декодирование символов. Декодирование символов можно включить либо в меню (вкладка Trace | Load Symbols), либо путем добавления следующей переменной в переменные среды Windows.

_NT_SYMBOL_PATH: srv*c:\symbols*http://msdl.microsoft.com/download/symbols;

В пользовательском интерфейсе WPA очень удобно наблюдать за работой приложения. На рис. 6 показана нагрузка, вызванная приложением для воспроизведения мультимедиа и системными процессами. В модуле «CPU Usage (Sampled)» содержится общее описание всех системных процессов, информация о стеке вызовов и количестве переключений контекста ОС за выбранный интервал времени. На рис. 6 видно, что приложение даже в режиме ожидания дает дополнительную нагрузку CPU 0,5–2%, а системные процессы используют 2% ресурсов ЦП. Желаемая загрузка ЦП с запущенным приложением в режиме ожидания должны быть не выше 1%.



Рисунок 6. Представление загрузки ЦП в Windows Performance Analyzer

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

На рис. 7 показано представление с длительностью временной шкалы в 2 секунды. Приложение для воспроизведения мультимедиа (выделено синим) и сама система создают частые вызовы пробуждения.


Рисунок 7. Представление WPA - использование ЦП.

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


Рисунок 8. Представление WPA - стек вызовов.

Вызов WaitForSingleObject с небольшим временем ожидания столь же вредит энергоэффективности, как и вызов режима сна через 1 мс. Контекст потока приложения выключается через 2,5 мс, вызывая периодические нагрузки из-за заданного времени ожидания. Решение у этой проблемы простое: увеличить время ожидания до бесконечного и ожидать вызова заданий.

Изменение параметров обращания к таймеру и исключение вызова WaitForSingleObject существенно увеличило время работы системы от аккумулятора, как показано в таблице 4.


Таблица 4. Оптимизация времени работы от аккумулятора

 

Итоги

Частые обращения к таймеру могут оказывать существенное влияние на потребление электроэнергии (свыше 20% всей потребляемой энергии). Изменение параметров обращений к таймеру на значения по умолчанию дало возможность увеличить время работы системы от аккумулятора примерно на 140 минут. Изменение вызовов API Win32 дало возможность добиться результата в 19 минут - именно на такой период времени система теперь меньше работает от аккумулятора при запуске приложения в режиме ожидания. Впрочем, 19 минут - это очень много для приложения в режиме ожидания, значит, возможна дальнейшая оптимизация. Средства Battery Life Analyzer и Windows Performance Analyzer дают возможность подробно изучить потребление электроэнергии приложениями. Анализ потребления электроэнергии следует проводить еще на этапе разработки приложений.

 

Для получения подробной информации о возможностях оптимизации компилятора обратитесь к нашему Уведомлению об оптимизации.
Теги: