Perhaps we should add a method to each that would return precision/jitter/whathaveyou. that way you don't have to throw an exception or cause any error. OTOH, maybe you want to add an arg that says "at least this good" <shrug> At Thursday 2004-05-06 18:01, you wrote:
On Thu, 06 May 2004 18:25:32 -0500, Aaron W. LaFramboise wrote
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.
Ok.
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.
Ok.
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.
Well I think this is a case of documenting the environments where the higher resolution clocks / timers may be available. At the compiler OS level we can just fail to compiler if the high resolution is not available. Even if it varies based on the hardware, we should be able to provide a program (such as the one you already wrote) that would allow a user to see how the clocks function in their environment and make a decision about whether they should use them.
For those that need something portable we should be able to get microsecond resolution for Windows, Linux, and probably a few more...
Jeff _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"