лекции / Shchupak_Yu._Win32_API_Razrabotka_prilozheniy_dlya_Windows

эти вопросы рассматриваются в книге К. Касперски [8]. Дело в том, что основу архитектуры любого процессора составляет конвейер, на котором выполняются микрооперации. Конвейер позволяет существенно повысить быстродействие про цессора. Но для конвейерной системы такое понятие, как «время выполнения одной команды», весьма условно. Конвейер принято характеризовать двумя па раметрами: «пропускной способностью» и «латентностью».

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

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

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

всовременных процессорах колеблется от 12 до 36 стадий. Опустив другие под робности, обсуждаемые в издании [8], приведем заключительную рекомендацию. Минимальный промежуток времени, которому еще можно верить при использо вании команды rdtsc, составляет по меньше мере от пятидесяти до ста тактов.

Другая тонкость, которую надо учитывать при профилировке, — это режим компиляции. Напомним, что в среде Visual Studio 6.0 этот режим определяется конфигурацией проекта. Возможны две конфигурации: отладочная (Win32 Debug) и выпускная (Win32 Release). Так вот, если вы занимаетесь профилиров кой, то используйте только выпускную конфигурацию! Иначе результаты будут искажены, поскольку в код отладочной конфигурации компилятор вставляет до полнительные отладочные инструкции.

Вернемся к вопросу определения поправки overhead, с помощью которой учи тываются «накладные расходы» в реализации функции GetCycleCount. Дело в том, что если выполнить фрагмент кода

t_start = GetCycleCount();

// профилируемый участок кода отсутствует t_stop = GetCycleCount() - t_start;

то мы получим ненулевое значение t_stop. Казалось бы, полученное значение и надо присвоить переменной overhead. Но при многократных испытаниях при веденного фрагмента обнаруживается, что результаты его выполнения почти всег да будут разными. Так, для нашего процессора были получены значения 88, 100, 84, 320. Такое непостоянство, по видимому, связано с теми особенностями функ ционирования конвейера, о которых говорилось выше. При этом ясно, что мини мальное значение, в данном случае 84, и есть истинное значение, так как никакие побочные эффекты не могут привести к ускорению работы программы.

Таким образом, для правильного определения величины overhead необходимо повторить указанный выше фрагмент несколько раз и выбрать наименьшее зна чение. Эксперименты показали, что достаточно сделать десять таких замеров для достижения устойчивого результата.

На точность градуировки счетчика TSC влияет еще один фактор. Это погреш ность отсчета эталонного интервала времени с помощью функции Sleep. Как бу дет показано в следующем разделе1, наибольшей точности отсчета можно достичь, если предварительно выполнить две инструкции:

timeBeginPeriod(1);

Sleep(20);

а уже после этого выполнять код для градуировки счетчика, приведенный выше. Функция timeBeginPeriod(1), согласно спецификации в MSDN, устанавлива ет разрешение системного мультимедийного таймера, равное 1 мс. И как пока

зали эксперименты, этот вызов влияет также и на работу функции Sleep. После окончания градуировки в указанном режиме необходимо вызвать функцию timeEndPeriod(1), чтобы освободить системные ресурсы, используемые для под держания высокоточного разрешения.

Для применения функций timeBeginPeriod и timeEndPeriod необходимо добавить в начало файла следующую директиву:

#include <Mmsystem.h>

а также подключить к проекту мультимедийную библиотеку winmm.lib2. Изложенные выше соображения учтены при разработке класса KTimer, объек

ты которого могут использоваться как высокоточные «хронометры». Исходный текст класса KTimer приведен в листинге 10.1. За основу взят код одноименного класса из [6], но здесь он доработан, чтобы повысить точность калибровки и пре доставить разработчику более удобный сервис.

В файле main.cpp рассматриваемого приложения осуществляется тестирова ние класса KTimer.

Листинг 10.1. Проект KTimer

//////////////////////////////////////////////////////////////////////

// KTimer.h #ifndef KTIMER_H #define KTIMER_H

1 «Программирование задержек в исполнении кода».

2Для Visual Studio 6.0 нужно использовать команду меню Project Settings…, перейти на вкладку Link, после чего ввести имя в текстовое поле Object/library modules.

Листинг 10.1. (продолжение)

double nCyclePer1microSec; double nCyclePer1milliSec;

double divizor; // текущий делитель public:

KTimer(void) {

//Калибровка overhead overhead = 0;

for (int i = 0; i < 10; ++i) { t_start = GetCycleCount(); et[i] = GetTick();

}

overhead = et[0];

for (i = 1; i < 10; ++i)

if (et[i] < overhead) overhead = et[i];

//Калибровка делителей timeBeginPeriod(1); Sleep(20);

Start();

Sleep(1000);

t_stop = GetCycleCount() - t_start - overhead;

divizor = nCyclePer1milliSec; // делитель по умолчанию

}

void SetUnit(TimeUnit unit) { switch (unit) {

case Msec: divizor = nCyclePer1milliSec; break;

case Ns_100: divizor = nCyclePer100nanoSec; break;

}

}

inline void Start(void) { t_start = GetCycleCount(); }

inline int GetTick(void) {

return (int)(GetCycleCount() - t_start - overhead);

}

inline double GetTime(void) {

t_stop = GetCycleCount() - t_start - overhead; return t_stop / divizor;

}

inline int GetTickPerUsec(void) { return (int)nCyclePer1microSec; } inline void uDelay(int uSec) {

int tElapsed = 0; SetUnit(Usec);

494 Глава 10. Таймеры и время

Start();

while ( tElapsed < uSec) tElapsed = (int)GetTime();

}

int GetOverhead() { return overhead; }

};

#endif /* KTIMER_H */

//////////////////////////////////////////////////////////////////////

// Main.cpp

#include <windows.h> #include <Mmsystem.h> #include <fstream> #include <iomanip> using namespace std;

#include "KWnd.h" #include "KTimer.h"

KTimer timer1;

KTimer timer2;

KTimer timer3;

#define N 5000000

int dTicks[N]; // число тактов счетчика TSC при профилировке нулевого участка double grossWorkQuant[N]; // кванты времени работы приложения (брутто) ofstream flog;

LRESULT CALLBACK WndProc(HWND, UINT, WPARAM, LPARAM); //====================================================================

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)

{

MSG msg;

KWnd mainWnd("Тестирование класса KTimer", hInstance, nCmdShow, WndProc); while (GetMessage(&msg, NULL, 0, 0)) {

TranslateMessage(&msg);

DispatchMessage(&msg);

}

return msg.wParam;

}

//==================================================================== LRESULT CALLBACK WndProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)

{

HDC hDC; PAINTSTRUCT ps; int i, No = 0; char text[200];

double netWorkQuant; // квант времени работы приложения (нетто)

а затем осуществлять профилировку участка кода следующим образом:

timer.Start();

// ... профилируемый участок

double elapsedTime = timer.GetTime();

По умолчанию объект timer настроен на измерение времени в миллисекундах. Вы можете изменить разрешение хронометра, вызвав предварительно (до вызова метода Start) метод SetUnit. Этот метод принимает в качестве параметра одну из кон стант перечисляемого типа TimeUnit, которые соответствуют единицам измерения 1 мс, 1 мкс, 100 нс, 10 нс, 1 нс. Заметим, что при тактовой частоте процессора поряд ка 2 ГГц устанавливать единицы измерения менее 100 нс нецелесообразно (см. из ложенные выше замечания о профилировке программ на конвейерных системах).

Если вместо метода GetTime применить метод GetTick, то будет реализована про филировка, результаты измерения которой выражены в тактах счетчика TSC. Этот метод может оказаться полезным для проведения экспериментальных исследова ний взаимодействия Windows и пользовательского приложения.

Класс KTimer содержит также метод uDelay, реализующий задержку в исполне нии кода, заданную в микросекундах. Но эта тема будет обсуждаться в следую щем разделе.

А теперь обратимся к коду файла main.cpp, написанному для тестирования клас са KTimer. В глобальной области видимости определены три таймера класса KTimer: timer1, timer2 и timer3. Работа с таймерами происходит в оконной процедуре при обработке сообщения WM_CREATE. Попутно здесь же осуществляется эксперимент по наблюдению за многозадачностью, реализуемой операционной системой Windows.

Идея эксперимента довольно проста. В теле цикла for, выполняемом N раз, нахо дятся инструкции для профилировки программного участка нулевой длины. Профи лировка выполняется вызовом методов timer1.Start() и timer1.GetTick(). Если GetTick возвращает нулевое значение, значит, «все нормально» и приложению никто не ме шает спокойно работать. Если же dTicks[i] > 0, это свидетельствует о вмешательстве Windows. Понятно, что система переключилась на обслуживание других задач. Ве личина dTicks[i] в этом случае характеризует квант времени, в течение которого наше приложение «отдыхает». С помощью таймера timer2 в этот момент фиксируется гру бая оценка grossWorkQuant[i] для предыдущего кванта времени, в течение которого приложение проработало. Оценка считается грубой из за того, что эта величина на самом деле представляет собой сумму «рабочего» кванта и кванта «отдыха». Общее время totalTime выполнения цикла for фиксируется с помощью таймера timer3.

После завершения цикла результаты измерений, сохраненные в массивах dTicks и grossWorkQuant, обрабатываются, чтобы их можно было сохранить в файле про токола flog.txt. В файл выводятся только те измерения, в которых значение dTicks[i] отличается от нуля. Каждая строка протокола содержит порядковый номер стро ки, номер прохода в цикле for, количество тактов счетчика TSC для профилиров ки «нулевого» участка, продолжительность «кванта отдыха» приложения и про должительность «кванта работы» netWorkQuant.

Эксперименты с приложением KTimer на нашем компьютере показали, что при значениях N, не превышающих 100 000 (при общем времени totalTime около 9 мс), Windows не прерывает работу приложения и в массиве dTicks не фиксируется ни одного ненулевого значения1.

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

Результаты испытаний программы для N = 5 000 000 (пять миллионов) выгля дят примерно так, как показано в листинге 10.2.

Листинг 10.2. Содержимое файла flog.txt после прогона программы с N = 5 000 000

Отклонения измерений dTicks от ожидаемого значения 0

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

Представленный класс KTimer можно использовать в качестве измерительно го инструмента в любом приложении. Для этого достаточно скопировать и под ключить к вашему проекту файл KTimer.h, после чего нужно добавить директиву #include "KTimer.h" в исходный текст тех файлов, где используются объекты это го класса. Также необходимо подключить к проекту мультимедийную библио теку winmm.lib.

Программирование задержек в исполнении кода

При создании реальных программ часто возникает необходимость «притормозить» исполнение кода в том или ином месте программы. В качестве простейшего при мера можно привести игровую программу, перемещающую некий графический объект по экрану с помощью цикла while. Предположим, что вы отладили вашу программу на компьютере с процессором, имеющим тактовую частоту 500 МГц. Что произойдет, если эта программа будет исполняться на более мощном компь ютере с тактовой частотой процессора 2 ГГц? Если не предусмотреть специаль ных мер, то объект будет двигаться гораздо быстрее, и не исключено, что играть станет совершенно невозможно. Типичное решение проблемы заключается в определении характеристик процессора и добавлении программируемых задер жек в таких циклах. Другой пример, с которым мы столкнулись совсем недавно, —

использование программируемой задержки для калибровки счетчика меток ре ального времени в классе KTimer.

Использование функции Sleep

Самый простой способ обеспечения задержки реализуется вызовом функции

Sleep:

VOID Sleep(DWORD dwMilliseconds);

Функция приостанавливает выполнение потока на то количество миллисекунд, которое указано в качестве параметра.

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

Листинг 10.3. Проект SleepTest1

//////////////////////////////////////////////////////////////////////

// SleepTest.cpp #include <windows.h> #include <stdio.h> #include <Mmsystem.h>

#include "KWnd.h" #include "KTimer.h"

KTimer timer;

#define SLEEP_TIME 1 #define N 100

double realTimeInterval[N];

LRESULT CALLBACK WndProc(HWND, UINT, WPARAM, LPARAM); //====================================================================

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)

{

MSG msg;

KWnd mainWnd("SleepTest", hInstance, nCmdShow, WndProc); while (GetMessage(&msg, NULL, 0, 0)) {

TranslateMessage(&msg);

DispatchMessage(&msg);

}

return msg.wParam;

}

//==================================================================== LRESULT CALLBACK WndProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)

{

HDC hDC; PAINTSTRUCT ps;

static int x, y;

продолжение

1Для нормальной компиляции и сборки проекта не забудьте подключить к проекту мультимедийную библиотеку winmm.lib (см. предыдущий раздел).

EndPaint(hWnd, &ps); break;

case WM_DESTROY: PostQuitMessage(0); break;

default:

return DefWindowProc(hWnd, uMsg, wParam, lParam);

}

return 0;

}

//////////////////////////////////////////////////////////////////////

Впрограмме производится профилировка функции Sleep с помощью объекта timer класса KTimer. Профилирующий код находится в блоке обработки сообще ния WM_CREATE.

Испытания повторяются N раз с помощью цикла for. Результаты измерений

вмиллисекундах сохраняются в массиве realTimeInterval.

Вблоке обработки сообщения WM_PAINT определяются минимальное, макси мальное и среднее значения для реальной задержки. Эти величины выводятся

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

В табл. 10.1 приведены результаты тестирования для разных значений SLEEP_ TIME.

Таблица 10.1. Реальная задержка, обеспечиваемая функцией Sleep

Из приведенных данных видно, что реальная задержка, обеспечиваемая функци ей Sleep, находится в некоторой области ближайшего большего значения, кратно го разрешению системного таймера (15,625 мс).

Теперь обратите внимание на инструкцию Sleep(20), помеченную в програм ме номером #2. Если ее убрать, то самый первый вызов функции Sleep(SLEEP_TIME) даст результат realTimeInterval[0], значительно отличающийся от последующих вызовов. При малых величинах SLEEP_TIME отклонения от среднего значения до стигают 80 %, а для задержки в 1000 мс — порядка 10 %. Трудно дать внятное объяснение этому факту, пользуясь информацией из справочной системы MSDN. Но, конечно, следует принять его во внимание, когда вы используете функцию Sleep для калибровки измерительного инструмента (см. исходный текст класса

KTimer).

Наши дальнейшие эксперименты показали, что разрешение функции Sleep можно существенно повысить, если предварительно вызвать функцию timeBegin Period(1), которая относится к мультимедийной библиотеке Windows. Эта функция устанавливает разрешение системного мультимедийного таймера, рав ное 1 мс.

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