Resolution of core.time.Duration...

Jonathan M Davis jmdavisProg at gmx.com
Wed May 18 03:12:01 PDT 2011


On 2011-05-18 02:13, Alexander wrote:
> On 18.05.2011 01:18, Jonathan M Davis wrote:
> > A monotonic clock is as good as you're going to get for accurate
> > stopwatch functionality. The system cannot possibly do any better than
> > that. Context switching can always get in the way. Increasing precision
> > doesn't help that.
> 
>   Probably, you have misunderstood me - I wasn't talking about precision. I
> was talking about the usage of real-time clock for benchmarking, which may
> be incorrect when you use real-time clock for measuring performance of
> CPU-bound tasks.
> 
>   Say, you have to benchmark something that heavily is using CPU - and this
> takes 10s. But when the system is doing something else - the real-time
> clock may differ significantly to CPU-clock.
> 
>   So, in my example, 10s of CPU-intensive work may take 20s of real-time,
> if another CPU-bound task is running at the same time, thus, benchmark
> results will be incorrect.

To my knowledge, using the system's monotonic clock is the absolute best that 
you're going to get for stuff like benchmarking. Are you suggesting that there 
is an alternative which is better? 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.

- Jonathan M Davis


More information about the Digitalmars-d mailing list