Re: [boost] high_resolution_timer \ timer feature requests forBoost.Timerr

From: Jeff Garland (jeff_at_[hidden])
Date: 2005-03-06 19:03:02

On Fri, 04 Mar 2005 16:09:55 -0500, James Fowler wrote

A few more thoughts here.  I think the conversion to Boost date-time types
gets you most of what you want here:
 
>     * interface issues for capturing durations
>           o consistent, portable representation

date-time time_duration does this.

>           o normalized conversion(s) for use in external expressions
>             (i.e., as double representing seconds)

I find the lossy arithmetic associated with doubles a non-starter for
date-time applications.  Boost date-time uses integer types and provides
fractional seconds breakdowns for time_durations.

>           o support for internal expressions (add, subtract, compare)

date-time time_duration does this.

http://www.boost.org/doc/html/date_time/posix_time.html#date_time.posix_time.time_duration

>           o variety of use cases for establishing boundary moments
>                 + constructor starts, destructor stops (and stores to
>                   target provided to constructor)
>                 + manual start / pause / continue / stop / restart
>                   (clear accumulated duration)
>                 + auxiliary class (takes reference to instance of
>                   duration, constructor calls start|continue, destructor
>                   calls stop)
>                 + and numerous other variations on the theme...

These would be additions to the current timer interface. See 

http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?GDTL/Timer

for a proposal on how this might look.  Please add / modify as you see fit.

>           o support for iostreams

Supported by time_duration.

>           o represented as a class (possibly templatized on mechanism
>             for actual time capture)
>                 + internal representation of
>                   start_time/stop_time/accumulated duration can be based
>                   on portable POD types

Yep.  Boost date-time is quite portable because it uses types like
boost::int64_t under the hood.

>     * interface for capturing high resolution time
>           o can be very challenging to balance:
>                 + resolution (as high possible??? !!!)
>                 + reliability and accuracy (otherwise resolution doesn't
>                   mean much...)
>                 + efficiency (all this with zero runtime overhead
>                   please, and fetch me a fresh cup of coffee while
>                   you're at it)
>           o variations in interface
>                 + hard to find one ideal portable API to build on, lots
>                   of choices
>                       # ACE has some nice timer wrappers
>                        

Dealing with unstable clocks is a nasty problem.  That said, with date-time
it's been isolated so that if you can write a better clock for a platform we
should be able to plug it into the new timer framework.

>...snip...a whole bunch more stuff
>....
> Hopefully this gives a taste of the complexities surrounding the 
> seemingly simple task of getting a precise representation of "now".  

Agreed.  I'm hoping if we build on boost date-time it will be much easier
though.  Basically it should be down to writing new and unique clocks with
different properties that plug into the timer.

Jeff