> На "железные" часики все равно сесть нельзя. На них уже OS > сидит и задачи по ним планирует. > А для большинства задач вообще time() достаточно. Для кого > не достаточно, тому GetTickCount() выше крыши. > Никто же, в конце концов не додумывается писать real time > систему в многозадачной OS ;)
Так ведь человеку нужно знать время, и поточнее, между двумя событиями! Поэтому может подойти такой вариант — хоть и на железные часики сесть нельзя, но на процессорные тики можно. Более того, это очень точная штука, поскольку в секунду процессор выполняет миллионы (а в последнее время и миллиарды) простейших операций в секунду. Итак, суть следующая: практически все современные процессоры имеют машинную инструкцию rdtsc, которая заталкивает в регистровую пару 64-битное значение количества машинных тиков процессора с момента его включения, т.е. если вы считали это значение, а потом через секунду (примерно) считали новое значение, и процессор у вас имеет частоту 800 МГц, то вы увидите увеличение этого значения примерно на 800,000,000,000. По-моему, точнее не бывает. А количество тиков в секунду можно расчитать усреднённое за несколько выборок или же усреднять к общей сетке, поскольку скорости процессоров весьма дискретны (кто шарит в железе, может подсказать).
На дельфи можно написать вот такую функцию:
function GetCPUTimeStamp: Int64; register;
asm
DW $310F
end;
---
Машинная инструкция rdtsc абсолютно свободно "разрешена к использованию" в пользовательских процессах защищённых OS.
И ещё один плюс — высокая скорость работы, поскольку это не вызов API. К тому же метод пригоден для измерения очень маленьких промежутков времени — к примеру, когда надо измерить скорость работы двух различных реализаций одной функции (чтобы выбрать наилучший), метод вполне пригоден.
> Простой, но его значение "плывет" в зависимости от числа > задач, загруженности и т.д. и тики с точностью, равной > установленной виндой частоты таймера.
На "железные" часики все равно сесть нельзя. На них уже OS сидит и задачи по ним планирует.
А для большинства задач вообще time() достаточно. Для кого не достаточно, тому GetTickCount() выше крыши.
Никто же, в конце концов не додумывается писать real time систему в многозадачной OS ;)
Самый надёжный вариант13.09.02 08:54 Автор: HandleX <Александр М.> Статус: The Elderman
> На "железные" часики все равно сесть нельзя. На них уже OS > сидит и задачи по ним планирует. > А для большинства задач вообще time() достаточно. Для кого > не достаточно, тому GetTickCount() выше крыши. > Никто же, в конце концов не додумывается писать real time > систему в многозадачной OS ;)
Так ведь человеку нужно знать время, и поточнее, между двумя событиями! Поэтому может подойти такой вариант — хоть и на железные часики сесть нельзя, но на процессорные тики можно. Более того, это очень точная штука, поскольку в секунду процессор выполняет миллионы (а в последнее время и миллиарды) простейших операций в секунду. Итак, суть следующая: практически все современные процессоры имеют машинную инструкцию rdtsc, которая заталкивает в регистровую пару 64-битное значение количества машинных тиков процессора с момента его включения, т.е. если вы считали это значение, а потом через секунду (примерно) считали новое значение, и процессор у вас имеет частоту 800 МГц, то вы увидите увеличение этого значения примерно на 800,000,000,000. По-моему, точнее не бывает. А количество тиков в секунду можно расчитать усреднённое за несколько выборок или же усреднять к общей сетке, поскольку скорости процессоров весьма дискретны (кто шарит в железе, может подсказать).
На дельфи можно написать вот такую функцию:
function GetCPUTimeStamp: Int64; register;
asm
DW $310F
end;
---
Машинная инструкция rdtsc абсолютно свободно "разрешена к использованию" в пользовательских процессах защищённых OS.
И ещё один плюс — высокая скорость работы, поскольку это не вызов API. К тому же метод пригоден для измерения очень маленьких промежутков времени — к примеру, когда надо измерить скорость работы двух различных реализаций одной функции (чтобы выбрать наилучший), метод вполне пригоден.
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
