progress_timer, incorrect timing
I got strange results with boost::progress_timer - it shows timings like 1.45s whereas it took about 15 sec. to complete a routine. It used to work ok, but I have no idea why it just doesn't work anymore! I use freebsd 4.11 and clocks_per_sec is defined 128. sysconf(_SC_CLK_TCK) also returns 128, but clock counter is not correct completely. I wrote simple test class, to see what's wrong: struct Timer { clock_t t; time_t tt; Timer() : t(clock()), tt(time(0)){} ~Timer(){ std::cout << "Elapsed interval: " << (static_cast<double>(clock() -t))/CLOCKS_PER_SEC << "s " << (time(0)-tt) << "s\n" ; } }; this is the output: Elapsed interval: 1.52344s 33s 1.52 s <- output by boost::progress_timer. so, you may see that measured time is completely wrong. I rewrote it with microtime(...) and it works correctly now. any ideas what's wrong, why clock() doesn't work anymore? Wouldn't that be a good idea to use microtime for unices? thanks
__PPS__ wrote:
any ideas what's wrong, why clock() doesn't work anymore? I'd hazard a guess that that's because it's measuring process CPU time rather than wall clock time. If you replace the thing you're timing with some solid computation, does clock() suddenly start giving the results you expect?
-- Will Bryant http://carcino.gen.nz/ will@core-dev.co.nz +64 21 655 443
Will Bryant wrote:
__PPS__ wrote:
any ideas what's wrong, why clock() doesn't work anymore?
I'd hazard a guess that that's because it's measuring process CPU time rather than wall clock time. If you replace the thing you're timing with some solid computation, does clock() suddenly start giving the results you expect?
If I understand right, what you say is that these delays are due to
interaction with the os and they are not counted by clock (for this
process)?
I didn't think about it, neither I found any info about that.
My example uses sqlite to insert thousands of rows of data. (disk or
ramfs access)
i'm writing a simple test example...
... ok, I verified, that timings are correct when ther's no interraction
with the os:
#include <iostream>
#include <ctime>
#include
__PPS__ wrote:
Will Bryant wrote:
__PPS__ wrote:
any ideas what's wrong, why clock() doesn't work anymore?
I'd hazard a guess that that's because it's measuring process CPU time rather than wall clock time. If you replace the thing you're timing with some solid computation, does clock() suddenly start giving the results you expect?
If I understand right, what you say is that these delays are due to interaction with the os and they are not counted by clock (for this process)?
clock() is supposed to indicate how much time the processor has spent running the process. It should exclude the time the process spends waiting for input/output operations to complete, or waiting in the runnable queue while other processes run. (Unfortunately in the MS C library (and maybe other C libraries for Windows) clock() indicates elapsed time since the process started, perhaps for compatibility with its behaviour under DOS, where the active process is never descheduled.) Ben.
__PPS__ wrote:
So, my measurements (from the original post) show time taken by my routine to execute, minus everything that's done by the OS?
In general, for a single-threaded program there's: 1. Time spent executing the program itself 2. Time spent in library calls, in user mode (note that this includes libc on *nix and some of the Windows API implementations, so the distinction between OS and library is often not clear) 3. Time spent in the OS in kernel mode doing things for the program 4. Time when the process is blocked waiting on IO (from other processes or devices), or other kernel IPC events (semaphores, condition variables, message queues etc.) 5. Time when the process is runnable but some other process is running instead (ie. it has been preempted). Which of these are included in the measure of "time" depends on the timing API, but in the case of "clock" which gives CPU time I'd expect it to include 1, 2, and possibly 3 (depends on the OS implementation), but not 4 or 5, during which time the process is just waiting to be resumed. If you're using "sleep" or similar APIs that may or may not be counted, depending on the implementation. "Wall clock", the elapsed real time, will include all 5. So you need to distinguish between wall clock time and the process CPU time, and choose which is appropriate for your timing application. For example, if benchmarking an application that uses an out-of-process database server, you would most likely want to include the time spent waiting for the SQL server to do its thing and so would want wall clock time, but if all you're interested in is the time taken to execute the actual computations in the process (the traditional example being billing on multiuser time-sharing systems, not a very common situation these days) then you might consider CPU time more appropriate. -- Will Bryant http://carcino.gen.nz/ will@core-dev.co.nz +64 21 655 443
participants (3)
-
__PPS__ -
Ben Hutchings -
Will Bryant