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

From: Jeff Garland (jeff_at_[hidden])
Date: 2004-05-02 21:55:02

On Sun, 02 May 2004 20:08:49 -0500, Aaron W. LaFramboise wrote

> I'm a little curious whats in the works for date_time clock support.
> Specifically, there still doesn't seem to be anything better than a
> second-granularity clock for Win32.

It depends on which compiler you use on Win32.  Those that support a posix
interface (eg gcc on cygwin).  I think Borland and some other might as well. 
  But yes, there should probably be a Win32 version that uses file time.
 
> In addition, the UNIX clock is not always as precise as it could be.
> In particular, the popular Pentium and and some other architectures
> have some sorts of cycle-granularity hardware clock or similar that
> can exceed the usual operating system clock used for time.

Ok.

> Really--and I have no idea what work is presently being done on
> this--it might do people in some problem domains (including myself,
>  at times) a lot of good to have clocks with separate notions of precision
> and accuracy.  For example, on a Pentium, operating systems I care
> about tend to have a maximum system clock accuracy around about a
> millisecond plus or minus some, and its probably difficult or tricky
> to get better than that.  

The 'microsec_time_clock' class uses gettimeofday -- an interface that can
support up to microsecond resolution.  Of course if the clock isn't that
accurate, the results won't be either. 

> However, if the system clock was used in
> combination with the Pentium cycle counter, we could probably get
> precision in excess of a nanosecond.  

With what algorithm would we achieve this?  It's not obvious to me how this
would work...

>Perhaps an interface for such a
> clock system might be:
> typedef boost::date_time::clock<type_of_accuracy_you_need_here,
> type_of_precision_you_need_here> myclock;
> To get the above imagined clock, I might use:
> clock<microsecond_accuracy, cycle_precision>
> 
> If the clock requested was unavailable on the platform, a compile 
> time error might result.

Sure we could do something like that, but it might be simplier to have a few
predefined types that work commonly.  

> Of course, oftentimes we know the characteristics of a clock's
> accuracy or precision, such as the Pentium cycle counter, but we 
> don't know exactly how precise it is, so it might be inappropriate 
> to refer to that clock as nanosecond_precision when it really might 
> not be.
> 
> In summary, a reliable cross-platform sub second clock is one of the
> features I miss most in date_time, and one of the features I can
> afford to miss least.  Is anyone working on remedying this right now?

Not explicitly, but I'm willing to work with you or anyone else on this.  One
of the core design principles of date_time is that it should be easy to add a
new clock without altering the core temporal types.  If you take a look at
boost/date_time/microsec_time_clock.hpp you can see it isn't that difficult to
 adapt an API to provide the time.  The main issue is figuring out which API
to use and how to adapt it into providing the current a yyyy-mm-dd
hh:mm:ss.fraction_seconds information.  

Jeff