From: Jeff Garland (jeff_at_[hidden])
Date: 2004-04-24 12:17:48
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.
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?GDTL/Timer
Jeff