--- wine/dlls/kernel/cpu.c 2004-12-29 12:09:47.000000000 +0100 +++ mywine/dlls/kernel/cpu.c 2005-01-19 12:39:15.000000000 +0100 @@ -188,7 +188,8 @@ BOOL WINAPI QueryPerformanceCounter(PLAR /* i586 optimized version */ __asm__ __volatile__ ( "rdtsc" : "=a" (counter->u.LowPart), "=d" (counter->u.HighPart) );
- counter->QuadPart = counter->QuadPart / 1000; /* see below */
/* see below */- counter->QuadPart = counter->QuadPart / ( cpuHz / 1193182 ) ; return TRUE; }
#endif
Don't we loose some precision here or are we sure that all PC clocks are exact multiples of '1193182' ?
Moreover, anyone has any idea how to do this without using RDTSC (which is a bad idea on most laptops and may well be on modern CPUs too if any implement the laptop-like power saving features) ?
Lionel
On Sun, 23 Jan 2005 14:29:02 +0100, you wrote:
--- wine/dlls/kernel/cpu.c 2004-12-29 12:09:47.000000000 +0100 +++ mywine/dlls/kernel/cpu.c 2005-01-19 12:39:15.000000000 +0100 @@ -188,7 +188,8 @@ BOOL WINAPI QueryPerformanceCounter(PLAR /* i586 optimized version */ __asm__ __volatile__ ( "rdtsc" : "=a" (counter->u.LowPart), "=d" (counter->u.HighPart) );
- counter->QuadPart = counter->QuadPart / 1000; /* see below */
/* see below */- counter->QuadPart = counter->QuadPart / ( cpuHz / 1193182 ) ; return TRUE; }
#endif
Don't we loose some precision here or are we sure that all PC clocks are exact multiples of '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.
Moreover, anyone has any idea how to do this without using RDTSC (which is a bad idea on most laptops and may well be on modern CPUs too if any implement the laptop-like power saving features) ?
No idea what timer quality the typical application using this function requires. Probably less then rdtsc, or it would have used it directly.
How bad is it to use the gettimeofday() method?
Rein.
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
On Mon, 24 Jan 2005 15:08:56 +0100, you wrote:
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).
I was more concerned about the accuracy of gettimeofday (not incrementing in usec's). So I did a small test and I find it behaves very nicely.
That was the only reason I could see to justify the rdtsc method, so here it goes. As the cpuHz variable is not used anymore, we might as well move it to ntdll.
Changelog: dlls/kernel : cpu.c dlls/ntdll : nt.c include : winternl.h
Get rid of the rdtsc cpu instruction method for calculation of the performance counter. Put the calculation (based on gettimeofday) in NtQueryPerformanceCounter() and use that in the kernel functions.
Rein.
Hi,
On Tue, Jan 25, 2005 at 06:44:04PM +0100, Rein Klazes wrote:
On Mon, 24 Jan 2005 15:08:56 +0100, you wrote:
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).
I was more concerned about the accuracy of gettimeofday (not incrementing in usec's). So I did a small test and I find it behaves very nicely.
That was the only reason I could see to justify the rdtsc method, so here it goes. As the cpuHz variable is not used anymore, we might as well move it to ntdll.
(sorry for not replying earlier - no time :-) I'm not sure why you'd want to base it on gettimeofday(). This is a terrible idea IMHO. I'm quite certain that many programs use that function for extremely time critical code (games, anyone??), and that thus the Windows function is equally highly optimized, certainly much less slow than a gettimeofday() call.
This should remain based on rdtsc IMHO, or on equally suitable and fast methods (ACPI counter, ...).
Or did you actually test it with programs calling it a large number of times, or test its performance behaviour on Windows?
Andreas Mohr
On Tue, 25 Jan 2005 19:30:04 +0100, you wrote:
I'm quite certain that many programs use that function for extremely time critical code (games, anyone??), and that thus the Windows function is equally highly optimized, certainly much less slow than a gettimeofday() call.
This should remain based on rdtsc IMHO, or on equally suitable and fast methods (ACPI counter, ...).
On my Windows machine (win2K) the calling sequence is kernel32->ntdll->hal. In other words a switch to kernel mode with associated overhead, similar to gettimeofday. I believe a program that would be critically depending on this will use the rdtsc instruction directly.
Why do you believe otherwise?
Or did you actually test it with programs calling it a large number of times, or test its performance behaviour on Windows
I did not. On Linux gettimeofday() is fast enough to match the resolution of the timer, approx. 1usec.
Rein.
I'm not sure why you'd want to base it on gettimeofday(). This is a terrible idea IMHO. I'm quite certain that many programs use that function for extremely time critical code (games, anyone??), and that thus the Windows function is equally highly optimized, certainly much less slow than a gettimeofday() call.
Well, if you find a way to do this that supports CPU with variable speed, feel free to submit a patch :-)
I had the case on my laptop: a game using the PerformanceCounter functions to get the current time was running super fast as it was getting the 'frequency' at the start (when the CPU was still in power / heat saving mode).
Forcing the 'gettimeofday' method got it working perfectly well whatever the cases.
Lionel
-
Andreas Mohr -
Lionel Ulmer -
Rein Klazes