__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