Jeff Garland wrote:
Very interesting. I'll play around with this. If the last 2 measurements are correct they would very precise clocks for timing.
Yes, except I am very concerned about some things. According to official documentation, QueryPerformanceCounter() does not garentee any particular precision. I'm not entirely sure, in fact, of what timing mechanism it uses myself. In addition, the docs mention that it may not even be implemented. rdtsc is excellent, and I think it has the most potiential of any of the clocks, except that there seems to be some considerable sentiment (Matt Gruenke on this list reminded me of this privately) that it is not terribly reliable as anything other than a cycle counter. In particular, there is rumor of laptops and similar that have the ability to alter their clock frequency runtime. (Compare to QueryPerformanceFrequency, where the documenation garentees the frequency will not change.) Also--I am not sure if this applies to any version of Windows yet or not--the operating system has the ability to completely disable rdtsc, supposedly for use in enforcing security in 'managed' environments. I think Linux does this. This fact somewhat limits the total applicability of rdtsc, especially on future hardware, where rdtsc may be routinely disabled. In both cases, at least in Win32, we can check if they are implemented before we start using them, but then we get this unfortunate situation with names. If a use asks for a nanosec_clock or whatever, but we can't determine until runtime that it isn't availible, what do we do? Throw an exception? Bet they won't be expecting that. Silently use millisec_clock instead? Big difference there. Just some things I am thinking about. Aaron W. LaFramboise