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

From: Beman Dawes (bdawes_at_[hidden])
Date: 2004-04-23 18:50:47

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.

--Beman