From: John Maddock (John_Maddock_at_[hidden])
Date: 2000-09-16 05:42:35
>The results were so varied that about the only thing you could say is that
>to truly optimize timing, you might have to make the clock() vs
>QueryPerformanceCounter() trade-off as late as run-time.
Perhaps I should have brought this up sooner but there was a long, um,
argument about this very issue on microsoft.public.win32.programmer.kernel,
the "discussion" related to whether the RTSC instruction should be used, or
whether QPC was better.
It seems that: RTSC is the highest resolution timer on an particular
machine, but "drifts" with respect to real time, there are also issues
relating to the new speed-step processors etc.
QPC will use RTSC on some multi-processor systems if Win32 can determine
that it is safe to do so (from the BIOS), otherwise the QPC latency is
quite long (as Beman discovered), but this appears to be necessary to
prevent "drift" with respect to real time (apparently MS had to change
their implementation at some point to correct this bug in an early "fast
but wrong" version). BTW the high latency of QPC does seem to be very
clock varies a heck of a lot: MS's version seems to have a much lower
latency on WinNT than on Win98 (where the call overhead is higher than
QPC), while Borland's version seems to have a lower latency than MS's
Note 1: in spite of having a lower latency on some systems, clock always
has an appalling resolution, the low latency is kind of irrelevent when the
accuracy is so low.
Note 2: I wander about the accuracy of clock over time - If the
implementation of clock misses out the synchronisation with real time that
QPC uses in order to reduce latency then I suspect that on *some* systems
the time returned by clock will drift.
I assume that the same issues that effect QPC also effect the NT only
GetProcessTimes function, but I don't have any hard information on that.
BTW from a personal point of view I still prefer QPC.
Sorry to open this particular can of worms again!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk