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

From: Victor A. Wagner Jr. (vawjr_at_[hidden])
Date: 2004-05-07 00:18:06

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_at_[hidden]
>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"