Hey all, I was looking at Boost.Timer and I noticed that it shows different results when it's used in a threaded program on Windows or Unix machines. A closer inspection revealed that it uses clock() to do it's timings. Digging a bit deeper I found that clock() is specified differently on Windows than it is in my Linux man-page. On windows it counts 'wall clock' time, basically what I'd expect from a class named timer but on Linux it counts CPU time. Thus it will give the result for completely different concepts of time elapsed depending on my system. Two questions; 1) is there a good way to solve this, 2) if not, could it at least be noted in the documentation. Thanks, Roel
It seems that there is an ancient Track ID for this problem as well https://svn.boost.org/trac/boost/ticket/1962 I've just added a comment there that illustrates the effect of clock() on Linux - Roel ________________________________________ From: boost-bounces@lists.boost.org [boost-bounces@lists.boost.org] On Behalf Of Jordans, R. [r.jordans@student.tue.nl] Sent: 29 October 2008 10:27 To: boost@lists.boost.org Subject: [boost] [Timer] Inconsistent behaviour Hey all, I was looking at Boost.Timer and I noticed that it shows different results when it's used in a threaded program on Windows or Unix machines. A closer inspection revealed that it uses clock() to do it's timings. Digging a bit deeper I found that clock() is specified differently on Windows than it is in my Linux man-page. On windows it counts 'wall clock' time, basically what I'd expect from a class named timer but on Linux it counts CPU time. Thus it will give the result for completely different concepts of time elapsed depending on my system. Two questions; 1) is there a good way to solve this, 2) if not, could it at least be noted in the documentation. Thanks, Roel _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Jordans, R. wrote:
Hey all,
I was looking at Boost.Timer and I noticed that it shows different results when it's used in a threaded program on Windows or Unix machines. A closer inspection revealed that it uses clock() to do it's timings.
Digging a bit deeper I found that clock() is specified differently on Windows than it is in my Linux man-page. On windows it counts 'wall clock' time, basically what I'd expect from a class named timer but on Linux it counts CPU time. Thus it will give the result for completely different concepts of time elapsed depending on my system.
Two questions; 1) is there a good way to solve this,
If you want a portable wall-clock timer and a simple Boost.Timer like interface you can just copy the boost/timer.hpp header file into your own namespace and rewrite it to use boost/date_time/posix_time stuff instead of ::clock(). I have done that before and it was really simple. There is a BOOST_ALL_NO_LIB macro you can define before you include the date_time headers so you avoid creating dependencies to anything but the header files in boost. -- Bjorn
On Wed, Oct 29, 2008 at 3:15 PM, Bjørn Roald <bjorn@4roald.org> wrote:
Jordans, R. wrote:
Hey all,
I was looking at Boost.Timer and I noticed that it shows different results when it's used in a threaded program on Windows or Unix machines. A closer inspection revealed that it uses clock() to do it's timings.
Digging a bit deeper I found that clock() is specified differently on Windows than it is in my Linux man-page. On windows it counts 'wall clock' time, basically what I'd expect from a class named timer but on Linux it counts CPU time. Thus it will give the result for completely different concepts of time elapsed depending on my system.
Two questions; 1) is there a good way to solve this,
If you want a portable wall-clock timer and a simple Boost.Timer like interface you can just copy the boost/timer.hpp header file into your own namespace and rewrite it to use boost/date_time/posix_time stuff instead of ::clock(). I have done that before and it was really simple. There is a BOOST_ALL_NO_LIB macro you can define before you include the date_time headers so you avoid creating dependencies to anything but the header files in boost.
I've got a much better timer with uniform behavior across Windows and POSIX. But I've been holding off submitting it until the C++0x date-time interfaces froze. That has now happened, and Howard Hinnant has made his proof of concept implementation available under the Boost license to use as a starting point for a Boost implementation. Maybe I can get something good enough to be useful together sometime in November. --Beman
Beman Dawes wrote:
I've got a much better timer with uniform behavior across Windows and POSIX. But I've been holding off submitting it until the C++0x date-time interfaces froze. That has now happened, and Howard Hinnant has made his proof of concept implementation available under the Boost license to use as a starting point for a Boost implementation. Maybe I can get something good enough to be useful together sometime in November.
--Beman _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I'm looking forward to it. I also ran into this issue some time ago and spun my own version using the boost::timer interface. michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
I've got a much better timer with uniform behavior across Windows and
POSIX.
Just FYI, I started a new & improved boost::timer interface a long time ago but had a crazy rush of work which made me put it on the side for a while. I should eventually find some time to finish it but I have no clue when this will happen. I'm not even sure it still works with the current version of boost. Here is my work: http://www.unitedsoft.ch/boost/ As you see, the main idea was to have a templated timer class that accepts a device class, which could use various apis for the timeing. Problems still to solve was thread safety, speed steping and how to hierachize them (should we provide compile-time selection as well?) in order to provide portable behavior. Hope it helps, Philippe
Hi Beman, There is also something that puzzled me in progress_timer. It sets the outpur precision of the stream to 2. Why this choice? -Thorsten
participants (6)
-
Beman Dawes -
Bjørn Roald -
Jordans, R. -
Michael Caisse -
Philippe Vaucher -
Thorsten Ottosen