boost::timers finalization
Hello guys, I finally got time on my hands to battle with quickbook and eventually I got it working ! So here's the (incomplete) documentation : http://www.unitedsoft.ch/boost/libs/timers/ And here's the current version of the timers library : http://www.unitedsoft.ch/boost/boost_timer_2007_30_4.tgz http://www.unitedsoft.ch/boost/boost_timer_2007_30_4.zip The documentation is not complete at all, but the main idea is there so I'd like you to express all the constructive criticism you guys might find about the library & documentation. Now I'll raise a couple of questions : 1. Does any of you have a better idea for the devices/timer names ? I'm not very fond of "gstaft_device" to express "GetSystemAsFileTime's device" but I can't find a better way. I thought of a devices<getsystemtimeasfiletime>::type mpl approach but it doesn't sounds so nice either. 2. I renamed boost::timer to boost::timers because the templated timer class should not have the same name as the namespace it lives in, if you have another idea for the organisation please share. Like should I make the "portable" namespace at all ? If not, should I move the devices/timers in that namespace in the boost::timers namespace ? 3. Does anyone know if std::clock() isn't implemented on "linux" ? On the unbuntu and gentoo boxes I tried it keeps returning 0, while on windows it works. 4. Does anyone know what's wrong in my getrusage() or GetThreadTimes() usage ? I can't see what's wrong but it also returns 0. 5. I'm looking to know about the overhead & resolution for all the apis used, if you have such informations please tell me :) 6. Once finalized all this, what's next ? Should I put the whole thing in a boost review ? 7. Should I write unit tests for this library ? I'm afraid it wouldn't make a lot of sense... Thank you ! Philippe
Philippe Vaucher wrote:
3. Does anyone know if std::clock() isn't implemented on "linux" ? On the unbuntu and gentoo boxes I tried it keeps returning 0, while on windows it works.
It is implemented and works. I've got a 2.6.14 kernel 64-bit Gentoo with a 2.5 glibc. #include <ctime> #include <cmath> #include <iostream> #include <ostream> int main() { std::cout << "Start: " << std::clock() << std::endl; for(int i = 0; i < 10000; ++i) { double foo = std::sqrt(static_cast<double>(i)); std::cout << foo << "\b\b\b\b\b\b\b\b\b\b\b\b\b" << std::flush; } std::cout << "End: " << std::clock() << std::endl; } The program's output varies between 20000 and 90000. The first one is always 0. clock() is supposed to measure elapsed CPU time, but the initial value is unspecified. It's apparently always 0 in Linux. The resolution doesn't seem to be very high, though. Given that CLOCKS_PER_SEC is defined by POSIX to be 1000000 regardless of actual resolution, and given that the values are always "rounded" to steps of ten thousand, I'd guess the resolution is 100Hz. This is not as good as the kernel timer resolution of 1000Hz that I have configured. Sebastian Redl
On 4/30/07, Sebastian Redl <sebastian.redl@getdesigned.at> wrote:
It is implemented and works. I've got a 2.6.14 kernel 64-bit Gentoo with a 2.5 glibc.
I found why my device_doesn't work, it's because I time a usleep(), and for some reasons I ignore it refuses to work. Here's a code to illustrate it : #include <iostream> #include <cstdio> #include <ctime> #include <sys/time.h> using namespace std; inline void test_usleep(int milliseconds) { usleep(milliseconds * 1000); } inline void do_something() { for(int i = 0; i < 10000; ++i) cout << 1 << '\b' << flush; } int main () { cout << "testing with usleep" << endl; cout << "before: " << clock() << endl; test_usleep(5000); cout << "after : " << clock() << endl; cout << "testing with code" << endl; cout << "before: " << clock() << endl; do_something(); cout << "after : " << clock() << endl; return 0; } By me it displays : testing with usleep before: 0 after : 0 testing with code before: 0 after : 60000 Is this a known behavior of std::clock() ? Philippe
Philippe Vaucher wrote:
I found why my device_doesn't work, it's because I time a usleep(), and for some reasons I ignore it refuses to work.
The reason is simple: clock() times CPU time. usleep() sleeps - it doesn't use the CPU. Thus, no "time" elapses during the sleep. This, by the way, is something you should mention in the clock_timer docs. Sebastian Redl
The reason is simple: clock() times CPU time. usleep() sleeps - it doesn't use the CPU. Thus, no "time" elapses during the sleep.
Makes sense, but on windows it works even when I Sleep() so it confused me a bit. This, by the way, is something you should mention in the clock_timer docs. Oh yes it's already there in my local doc :) Thank you. Philippe
Hi there, I added a ftime_device, so now we have : - 4 portable devices. - 3 posix devices. - 5 win32 devices. I made a simple page with the latest library versions & documentation there : http://unitedsoft.ch/boost/ Thank you. Philippe p.s: while searching, I found two more posix apis: times() and ntp_gettime() from sys/time*.h, would there be an interest for those ?
On 5/1/07, Philippe Vaucher <philippe.vaucher@gmail.com> wrote:
The reason is simple: clock() times CPU time. usleep() sleeps - it doesn't use the CPU. Thus, no "time" elapses during the sleep.
Makes sense, but on windows it works even when I Sleep() so it confused me a bit. [snip]
Standard clock() measures CPU time, while Windows / MS DOS clock() measures elapsed time. Most of us could use the old boost timer otherwise. Moreover, Windows 95/98/ME did not provide alternative API to measure CPU time. NT based Windows became dominant only recently; otherwise the problem would be fixed long ago.
participants (3)
-
Philippe Vaucher -
Sebastian Redl -
Yuriy Koblents-Mishke