Resolution of core.time.Duration...

[Alexander]

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