Мне немного непонятна работа интсрукции RDTSC в многозадачных ОС. Ведь по-моему эта инструкция считывает 64-битное число с счетчика тактов процессора. А ведь исполнение программы постоянно прерывается менеджером процессов, и соотв. исполняется другой код, после чего управление передается нашей проге. Тогда rdtsc будет офигенно врать, ведь за определенный отрезок времени помимо нашего кода еще исполнилось дофига чужого.
mix_mix Миллисекунд за 10-20 может так случиться, что никто не прервёт. А что именно Вы от неё хотите? Замерять время выполнения инструкций для бенчмарка?
Quantum Ну было бы неплохо, чисто ради интереса знать за сколько тактов исполняется определенный блок инструкций. То-то я думаю: Неужели инструкция nop исполняется за 30000 тактов ?! (полу-шутка)
mix_mix Об этом rdtsc никогда не врёт Почему бы и нет? Не нравится многозадачность? - возьмите старенький дос или лучше реалтаймовый билд линукса.
rdtsc считает такты процессора. но никак не такты потока. хотите использовать rdtsc в качестве измерителя скорости - обеспечивайте непереключение процессора между потоками. либо юзайте секундомер.
mix_mix В работе самой инструкции RDTSC есть только один нюанс - на P4 Northwood она выдает результаты с дискретом в 4 такта, а на Prescott'ах вроде как все 8. (Ну также ес-но нужно учитывать, что это несериализованная инструкция) А твой вопрос видимо касается того, как правильно ее использовать для "точных" измерений. Этот вопрос не раз поднимался - можешь заглянуть в pentopt.pdf А.Фога и\или поискать по форуму - bogrus тут не раз выкладывал тестилку wintest (у cresta тоже должен быть свой вариантик - "многотестовый" . В двух словах "борьба" с виндовым планировщиком сводится к следующему: 1) заданием максимального приоритета процесса и потока REALTIME + TIME_CRITICAL 2) ограничением времени измеряемого куска кода < 10-20 мс. На частоте 1ГГц это будет < 10-20 млн. тиков - более чем достаточно. Можно также перед тестом вызывать Sleep(0), чтобы "гарантировать" запуск тестового куска с начала выделенного кванта. 3) обязательно в одном тесте проводить серию из 5-10 измерений, смотреть на повторяемость результатов и игнорировать большие выбросы если они есть. Это также нужно для исключения влияния возможных отказов страниц и подгрузки кода и данных из памяти в кэш - первые один-два результата всегда оказываются завышенными (если нужно оценивать именно отказы и загрузку, то для этого нужно создавть специальный тест). 4) ну и ес-но не провоцировать винду на прерывания и переключения контекстов - не запускать лишних процессов и не жать на кнопки и клавиши При соблюдении этих условий многозадачность измерениям не мешает - на нормальных 1 или 2-процессорных системах. А вот с дебильным HT - труба, как ни старайся но избавиться от разброса до нескольких сотен тиков практически невозможно. Тут остается только вылавливать из каши минимальные значения числа тиков. Еще один нюансец, связанный с хитростями работы процессоров - если для сериализации rdtsc как положено использовать cpuid, то при наличии в тесте записи в память результаты оказываются завышенными на десяток и более тиков (выталкивание буферов записи в кэш). PS: С учетом п.2) при использовании RDTCS не нужно накручивать "бесконечные" циклы с тысячами и миллионами повторений, как это деают при использовании GetTickCount. Тут должна рулить разумная достаточность
