On Mon, Jan 24, 2005 at 11:58:37AM +0100, Rein Klazes wrote:
- counter->QuadPart = counter->QuadPart / ( cpuHz / 1193182 ) ;
(...)
FYI, I traced this in windows (2K, XP), that gets the counter through some inp's and outp's to 0x40/0x43. That is historically an 8253 programmable interval time, aka timer0. The function is in the hal.dll, so it is possible that on some hardware this might be different.
Well, my question about loss of precision was not about the way Windows does it but in the way the computation is done in your code. As you divide the 'cpuHz' value by 1193182, if the former is not a multiple of the latter, some precision will be lost.
I agree though that it may be anecdotic.
No idea what timer quality the typical application using this function requires. Probably less then rdtsc, or it would have used it directly.
Nah, for once that Windows applications are portable and use Win32 APIs instead of direct ASM calls we should not complain :-)
How bad is it to use the gettimeofday() method?
In my opinion, the RTDSC method should be suppressed from the code and we should always use the 'gettimeofday' method (despite the penalty hit of a syscall).
At least have a way to force the 'gettimeofday' method.
Lionel