Re: [Boost-users] date_time clocks, microsec_clock, etc

From: Jeff Garland (jeff_at_[hidden])
Date: 2004-05-06 20:01:57

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