On 18.05.2011 12:12, Jonathan M Davis wrote: > To my knowledge, using the system's monotonic clock is the absolute best that > you're going to get for stuff like benchmarking.
It depends. If system is not busy, then it doesn't really matter - which clock to use, especially if you take average over several runs. If you benchmark I/O performance, then you need real-time clock and idle system - no way around. But if you benchmark CPU performance, the you have to use CPU clock - i.e. the clock which is increasing only when application is actually using CPU. > Are you suggesting that there is an alternative which is better? Sure, there is - clock_gettime with CLOCK_THREAD_CPUTIME_ID or CLOCK_PROCESS_CPUTIME_ID as clock id. This way, you will get exactly the amount of time that was spent while specific thread was using CPU. > As far as I know, the issues of context switching and whatnot are just a > part of life and that you can't do anything > about them except restrict what you're running on your computer when you run > benchmarks. The way I've described it (CLOCK_THREAD_CPUTIME_ID or CLOCK_PROCESS_CPUTIME_ID), or using simple clock() function (less precise, though) you can do this. It only doesn't work well with measuring I/O performance, as CPU is mostly waiting, so CPU time is useless. I would propose extension of StopWatch - an option to specify which clock to use, CPU or real-time (monotonic is real-time). /Alexander
