Энергопотребление процессора в архитектурах Intel®

Категории:

Введение

Влияние коротких интервалов прерывания от синхроимпульса и состояний сна на двухъядерные платформы Intel® для мобильных ПК.
Интерфейс Win32* обеспечивает различные программные интерфейсы API для периодического исполнения кода приложения с нужной частотой. В основе этого лежат периодические такты системных часов, встроенных в аппаратно-зависимый уровень (HAL) операционной системы Microsoft Windows*. Различные приложения, такие как проигрыватели мультимедийных файлов, имеют потоки для ввода/вывода дисков, декодирования, аудио-видеовывода и интерфейса пользователя. Обычно они используют временные прерывания для периодического исполнения раздела кода перед или во время заданного периода времени (например, воспроизводить аудиофайл каждые 90 миллисекунд и т. п.). Ниже приведены наиболее часто используемые в таких сценариях программные интерфейсы:

  • timeSetEvent(UINT uDelay, UINT uResolution, LPTIMECALLBACK lpTimeProc, DWORD_PTR dwUser, UINT fuEvent)

    Это мультимедийный таймер из ОС Win32, который выполняется в своем собственном потоке, доступном в библиотеке winmm.lib. Функция обратного вызова может выполняться периодически или по заданному графику, в зависимости от параметра fuEvent.
  • SetTimer(HWND hWnd, UINT_PTR nIDEvent,UINT uElapse, TIMERPROC lpTimerFunc) - доступно в user32.dll

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

Существуют дополнительные программные интерфейсы, такие как WaitableTimers(), QueuedTimers() и т. п.; однако все они пользуются системными часами для запуска регулярного исполнения кода.

Детализация интервалов прерывания

Обычно операционная система получает сигналы о периодических временных прерываниях каждые 10-15,6 миллисекунд. Рассмотрим в качестве примера приложение, которое использует программный интерфейс timeSetEvent() API для воспроизведения аудиоданных каждые 32 миллисекунды, а операционная система получает сигнал прерывания каждые 15 миллисекунд. Операционная система выполняет проверку сроков исполнения во время каждого такта и для первых двух тактов (то есть в течение 30-миллисекунд), когда срок воспроизведения в приложении не был соблюден. Во время третьего такта (через 45 миллисекунд) операционная система выясняет, что срок воспроизведения уже истек, и прекращает операцию. Проблема заключается в том, что воспроизведение будет задержано на 13 миллисекунд дольше, чем запрограммировано в приложении. Этот пример наглядно показывает, что на детализацию прерываний может повлиять своевременная активизация периодических вызовов.

Комплект для разработки Microsoft Windows Multimedia SDK содержит программный интерфейс timeBeginPeriod() API для изменения стандартной частоты прерывания в Windows XP, как минимум, на 1 миллисекунду. В приведенном ниже коде показан пример такого изменения.

Изменение разрешения интервала прерываний

void SetResolution(int delta)
{
	TIMECAPS tc;
	UINT     wTimerRes;
	if (timeGetDevCaps(&tc, sizeof(TIMECAPS)) == TIMERR_NOERROR)
{
		wTimerRes = min(max(tc.wPeriodMin,
    (UINT)delta), tc.wPeriodMax);
		timeBeginPeriod(wTimerRes); 
}
}

Увеличение детализации интервала прерывания позволяет повысить точность и своевременность периодических вызовов. Например, в приведенном выше примере, как только прерывания начнут запускаться каждую миллисекунду, воспроизведение будет начинаться вовремя. Однако увеличение детализации интервала прерывания приводит к существенному росту энергопотребления. Кроме того, не всякое мультимедийное содержимое может требовать такой высокой частоты прерывания. В следующих разделах анализируется влияние высокой частоты прерывания на спящие режимы и энергопотребление процессора в имеющихся и будущих архитектурах Intel. Анализ включает результаты экспериментов с несколькими мультимедийными приложениями, которые показывают, что можно поддерживать комфортные условия работы пользователя и общую производительность с помощью стандартного интервала прерывания для определенного медиасодержимого. Подробное обсуждение проблемы интервалов прерывания можно найти по адресу http://www.microsoft.com/whdc/system/CEC/mm-timer.mspx*.

Влияние интервалов прерывания на архитектуры Intel

Архитектуры Intel для мобильных устройств, такие как процессор Intel® Pentium® M, включают технологию Enhanced Intel SpeedStep® для оптимизации энергопотребления и производительности в соответствии с потребностями системы. Эта технология обеспечивает многоточечные операционные режимы (под названием P-State, где P0 - самая высокая тактовая частота процессора) процессора, которые увеличивают или уменьшают тактовую частоту процессора в зависимости от конкретных требований. При незначительных потребностях системы, когда процессор находится в неактивном состоянии, она обеспечивает многочисленные состояния сна процессора (под названием C-State; наивысший уровень C-состояний, такой как C4, соответствует состоянию боле глубокого сна), когда существенно снижается общее энергопотребление.

Каждое прерывание выводит процессор из состояния более глубокого сна в состояние C0, благодаря обработчику прерываний, который обслуживание прерывания. Это оказывает влияние на длительность состояний сна, которое имеет важное значение для оптимизации потребляемой энергии. При переходе из одного C-состояния в другое также происходит энергопотребление. Короткий интервал прерывания отрицательно сказывается на энергосбережении, происходящем благодаря состояниям сна, из-за уменьшения времени пребывания процессора в состоянии сна и энергозатрат, связанных с переходом из одного C-состояния в другое. Несмотря на то, что платформы Intel® обеспечивают специфичные для каждой платформы состояния сна типа C3, им требуется длительное время пребывания (несколько миллисекунд) для полной компенсации затрат на переход. Слишком короткий интервал прерывания может свести на нет преимущества состояний глубокого сна, обеспечиваемых данной платформой.

Влияние продолжительности C-State и энергопотребления процессора на процессор Intel® Core™ Duo (ранее Yonah)

Автор данной статьи использовал простой код тикера для анализа влияния короткого интервала прерывания на продолжительность C-состояния и среднее энергопотребление процессора Intel® Core™ Duo B0 (2,0 ГГц), 1 Гб 533, используемого для выполнения Microsoft WinXP*-SP2. Все данные об энергопотреблении, включенные в этот документ, были получены с помощью инструментария NetDAQ* центрального процессора. Приведенный ниже код (под названием MyTicker) берет параметр командной строки и бессрочно устанавливает соответствующий интервал прерывания и нерабочие режимы:

Код MyTicker.

int _tmain(int argc, _TCHAR* argv[])
{
	if (argc != 2) 
		return 1;
	int tick = (int)argv[argc];
	TIMECAPS tc;
	UINT     wTimerRes;
	HANDLE hThread;

	if (timeGetDevCaps(&tc, sizeof(TIMECAPS)) != TIMERR_NOERROR)  
	{
		return -1; //error
	}
	wTimerRes = min(max(tc.wPeriodMin, tick), tc.wPeriodMax);
	timeBeginPeriod(wTimerRes); 
	Sleep(INFINITE);
	return 0; //not reached!
}

В приведенных далее диаграммах проводится сравнение использования процессора, прерываний в секунду, продолжительности C3/C4 и средней мощности ЦП между кодом MyTicker 1 millisecond, который запускает прерывание с интервалом в 1 миллисекунду, и неработающей системой (IDLE), которая устанавливает стандартный интервал прерывания. Фиолетовая строка представляет неработающую систему (IDLE) со стандартным интервалом прерывания (~15,6 миллисекунды), а синяя представляет неработающую систему с частотой прерывания в 1 миллисекунду.



Рис. 1. Прерываний в секунду (MyTicker 1ms в сравнении с IDLE)

Как и ожидалось, здесь количество прерываний в секунду выросло с ~100 до ~1000.



Рис. 2. Продолжительность состояния сна (MyTicker 1ms в сравнении с IDLE)

Продолжительность %C3 здесь соответствует сравнительной продолжительности состояния сна (C3/C4) в двух сценариях. Поскольку количество прерываний в секунду выросло с ~100 до ~1000, продолжительность состояния C3 уменьшилась с ~97% до ~81%. Сокращение длительности состояния сна предполагает увеличение среднего энергопотребления ЦП.



Рис. 3. Среднее энергопотребление ЦП (MyTicker 1ms в сравнении с IDLE)

Как можно было убедиться, наблюдается существенный рост среднего энергопотребления ЦП (с ~0,5 Вт до ~1,05 Вт) при увеличении скорости прерываний. Ожидается, что энергопотери в следующих платформах будут значительно выше, чем эти, поэтому возникает потребность в приложениях, чувствительных к интервалу прерывания.

Анализ мультимедийных приложений

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

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

Поскольку мы должны были проанализировать разные приложения, источника которых у нас не было, была применена методология перехвата для перехвата и изменения программных интерфейсов таймера. Эта методология работает приблизительно так же, как библиотека Microsoft Detours*. На высоком уровне она действует с помощью изменения бинарного образа приложений для создания функции пропускания для программных интерфейсов таймеров. Далее приведен пример использования этой методологии с помощью программного интерфейса timeSetEvent().



Рис. 4. Методология перехвата API

На первом этапе код, содержащий функцию перехвата (функции MyIntercept и Trampoline), помещается в адресное пространство вызывающего процесса (Iexplore.exe). Первые несколько инструкций этой функции, которые нужно перехватить, перезаписываются с помощью команды безусловного перехода к функции MyIntercept. Функция Trampoline содержит перезаписанные инструкции и команду безусловного перехода назад к timeSetEvent(). Как только любой из текущих таймеров пройдет функцию MyIntercept(), можно изменить встроенный интервал прерывания, изменив значения стека в MyIntercept().

Значения прерывания в мультимедийных приложениях

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

Конечные результаты

В приведенной ниже таблице показаны итоговые результаты для мультимедийных приложений с коротким интервалом прерывания (1 миллисекунда по сравнению с 10 миллисекундами). Содержимое каждого из них не потребляет большое количество мощности ЦП на протестированном процессоре Intel Core Duo. Это оставляет большой простор для различных действий, а также соответствует такому режиму эксплуатации, когда воспроизведение не приводит к существенному использованию ресурсов. В таблицу включена продолжительность C0/C3 при среднем уровне энергопотребления ЦП. Показатель %C3Res включает длительность всех состояний C3 вместе с состояниями глубокого сна.

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

После того как частота прерывания была уменьшена с 1 миллисекунды до 10 миллисекунд, произошло заметное увеличение длительности C3 и сокращение длительности C0. Этот приводит к значительному энергосбережению ЦП (макс. 0,5 Вт) в зависимости от содержимого и приложения. Ожидается, что в последующих архитектурах энергосбережение значительно возрастет.

Постоянные прерывания

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



Рис. 5. Пример постоянно возобновляющихся прерываний

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

Вывод

  • Интервал прерывания существенно влияет на длительность состояния глубокого сна и энергопотребление ЦП. Ожидается, что в последующих платформах энергопотери существенно вырастут.
  • Многие медиаприложения используют очень короткий интервал прерывания (1 миллисекунда).
  • В зависимости от содержимого, можно поддерживать одинаковый уровень производительности пользователя при сокращении интервала прерывания, тем самым обеспечивая сбережение энергии ЦП.
  • Рекомендуется использовать высокий интервал прерывания (1 миллисекунда) только в тех случаях, когда медиасодержимое безусловно требует этого.
  • Многие приложения создают закрепленные прерывания, которые продолжают выполняться даже после завершения воспроизведения содержимого. Такие закрепленные прерывания уменьшают продолжительность состояния сна даже в период простоя. Рекомендуется отключать короткий интервал прерывания сразу после завершения воспроизведения.

Ссылки

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