max elapsed time of boost::timer
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, 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. toon
Toon Knapen <toon.knapen@fft.be> writes:
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, using clock() is not very usefull for doing timings of short (in time) events.
In my experience, clock() is significantly more accurate than 1 second.
Even more, for short events, the boost::timer might also influence the timing too much.
I believe that boost::timer is very light weight. This: { boost::timer t; /* ... */ double elapsed = t.elapsed(); } Should be equivalent (in efficiency) to: { std::clock_t initial = clock(); /* ... */ double elapsed = static_cast<double>(clock() - initial) / CLOCKS_PER_SEC; }
[snip: clock() useful only for longer timings]
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.
This can be remedied by storing the time internally using a 64-bit integer, and then providing a method which the user must call once per wraparound period in order to achieve accurate results.
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.
clock() serves as a process CPU-time timer, while time() depends on the system time, and is also affected by changes to the system clock. (Also, time() provides only second-precision.) There was talk of an additional wallclock_timer being added, however; to be useful, such a facility would ideally be based on a more precise time source than time(), such as gettimeofday. It appears that the date/time library includes the partially documented (only through doxygen) facility microsec_clock, which may or may not be functional on non-POSIX platforms. -- Jeremy Maitin-Shepard
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
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
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
participants (4)
-
Beman Dawes -
Jeff Garland -
Jeremy Maitin-Shepard -
Toon Knapen