Mark, Chris, Chris Albertson wrote: > Can't you take care of this in the build system? I never go near > Windows, the last version I used was Win 95. But on other systems I > always use something like the GNU Auto tools cmake or whatever and > part of the process is to check for the availability of each system > call and library and then the source is built using what's on that > specific machine. I'd guess that there is something like this in > Windows. Is GNU Autoconf ported to Windows? If so then use > QueryPerformanceCounter() if it is available. It seems much cleaner > to that care of this kind off thing in the build process
The QueryPerformanceCounter() (QPC) call is available on all Windows Versions since Windows NT. I'm not sure if it was supported on Windows 9x, though. The windows 9x versions were more like DOS with a graphical user interface. QPC is implemented in the Windows Hardware Abstraction Layer (HAL). At least Windows versions around XP were shipped with different versions of the HAL DLL, and the Windows installer determined during installation which version to use. The different versions used different timers on the particular PC, and depending on the timer which was actually used (TSC, HPET, PMTIMER, ...) the QPC call worked with different clock frequencies and thus provided different resolution. When Windows XP was current then current CPU types both from Intel and AMD had problems with the TSC since the TSC clock frequency could change when the CPU clock frequency changed due to power savings, and TSCs might not have been synchronized across different cores in the same physical CPU. This is why you could force Windows XP always to use the PMTIMER which is part of the ACPI support chipset, and if I remember correctly the SP3 for Windows XP did this automatically to avoid problems with the TSC. You can use the QueryPerformanceFrequency() call to determine the clock frequency of the timer used for QPC, and the frequency typically tells you which timer/counter circuit or the PC it actually is. One important point is that the TSC can be read very much faster than one of the other timers/counters since its just reading a CPU register, while other circuits are part of the chip set and need to be accessed via a peripheral bus. Modern Windows versions determine much more reliably if the TSC can be used without problems, or not, and use it, if appropriate. Modern Windows versions (Windows 8 an newer) also provide some new API calls which return the system time with higher resolution/precision than original API calls. For example, the original API call GetSystemTimeAsFileTime() only had a coarse resolution of 0.5 to ~ 16 ms, depending on the Windows version and some conditions. Now there's a new API call GetSystemTimePreciseAsFileTime() which always provides 100 ns precision/resolution. Similar with some other call for which there are "Precise" variant available now. A common practice is to check at runtime if a "Precise" call is supported by the OS version under which the application is currently running. For example, at program startup try to import the symbol GetSystemTimePreciseAsFileTime and set up a function pointer with it. If the symbol can't be imported (e.g. if running on windows XP) set the pointer to GetSystemTimeAsFileTime, and get system time stamps only by calls via that pointer. So you have a single executable which benefits from the "Precise" call if available, and falls back to the standard call if it's not available. This page https://msdn.microsoft.com/en-us/library/windows/desktop/dn553408%28v=vs.85%29.aspx provides a good overview of the available functions. Martin _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.