Re: [boost] max elapsed time of boost::timer

From: Jeff Garland (jeff_at_[hidden])
Date: 2004-04-24 12:17:28

On Fri, 23 Apr 2004 19:50:47 -0400, Beman Dawes wrote
> At 08:37 AM 4/21/2004, Toon Knapen wrote:
> 
>  >The documentation of boost::timer states that 'The maximum measurable
>  >elapsed time may be as low as 596.5 hours (or even less) ...'.
>  >
>  >Well on many 32bit platforms this would probably even be about 71 hours.
>  >Apparantly POSIX requires CLOCKS_PER_SEC to be 10e6, so if clock_t 
> is 32 >bit, the maximum of ( clock() / CLOCKS_PER_SEC ) is 4294 seconds.
>  >
>  >Because accuracy for clock() is generally about 1 sec,
> 
> As Jeremy Maitin-Shepard commented, clock() is usually better than 
> that. .001 seconds at least. But see comment below.
> 
>  > using clock() is
>  >not very usefull for doing timings of short (in time) events. Even 
> more, >for short events, the boost::timer might also influence the 
> timing too >much. So clock() is generally interesting for longer 
> timings (from 10 >sec onwards). > >But for long events the clock_t 
> wraps around too fast (as mentioned >above). And if you're unlucky 
> that you _start_time = clock() is or a bit >smaller than 
> std::numeric_limits< clock_t >::max() (thus near the >wrap-around 
> point), directly afterwards the expression 'clock() - start' >will 
> result in a negative value. > >So I would like to suggest for 
> boost::timer to use std::time_t and use >std::time(NULL) instead of 
> clock() and use std::difftime to calculate >the elapsed time.
> 
> boost::timer dates from the earliest days of Boost, when we were 
> limiting ourselves to implementations which used only the C++ 
> standard library.
> 
> boost::timer should really be redone (and then be reviewed) using 
> current Boost practice. Key changes:
> 
> * It should either become a part of the date-time library or at 
> least be made compatible with date-time. As a practical matter, that 
> means close coordination with Jeff Garland.
> 
> * Behavior should be specified, and then implementations done for 
> various platforms which meet that behavior. Specifying behavior such 
> that all platforms will behave in the same way, yet the behavior is 
> sufficiently useful, is non-trivial. The precision and latency of 
> native timing API's can change from release to release, so it is 
> important not to over-specify the behavior.
> 
> If anyone would like to volunteer to take that on as a project, it 
> would be appreciated.

I'd be happy to take on the task of moving the timer into date_time.  I've
been planning on doing this for awhile, but it just hasn't been a high
priority.  I'll try and dig up all the prior discussion on this topic and put
together an interface proposal.  I don't see why we can't try and target
something for the next release assuming we can do a collaborative development
and/or fasttrack review.

BTW, I believe the interfaces for the timer should be templatized to support
various 'clock devices' that can support different timing resolutions and
properties.  For example, if I happen to have an gps derived clock laying
around it would be nice to write a little adaptor and use it for a high
precision timer.  This can also help with portability since different
platforms can support different resolutions if need be.  That way the
interface doesn't have to be over-specified, but rather becomes platform driven.

I've started gathering material for this on the Wiki.  Others, please
contribute requirements and issues.  I'll post more when I think there is
something substantial to review.

Jeff