Author: Robert Hyatt
Date: 10:50:09 01/24/02
Go up one level in this thread
On January 24, 2002 at 05:45:47, JW de Kort wrote:
>On January 23, 2002 at 13:30:44, Robert Hyatt wrote:
>
>>On January 23, 2002 at 08:39:53, JW de Kort wrote:
>>
>>>Hi!
>>>
>>>Last week i decided it was time to speed up my evaluation function. In order to
>>>do so i inserted some code to keep track of the time spend in various parts of
>>>the evaluation function. Somthing like:
>>>
>>>int timeused []
>>>
>>>
>>>eval()
>>>{
>>> timeused[total]-=clock();
>>>
>>> timeuses[part1] -=clock
>>>
>>> // do some evaluation
>>>
>>> timeused[part]+=clock();
>>>
>>> timeuse [part2] -= clock();
>>> // do some other evaluation
>>> tumeuse [part2]-=clock();
>>>
>>> timeuse[total]+=clock();
>>>}
>>>
>>>
>>>Then i evaluated the time spend in the various parts. This was very
>>>disappointing: after 10 runs of the same number evaluations each run jused a
>>>different amount of time and the time spend in the various parts of the
>>>evaluation also different, not only in time used but also in time used as a
>>>percentage of the total time spend evaluating. These difference where not small
>>>but rather large. In one word: useless!
>>>
>>>Can anybody explain this behaviour? And is there a better way to time?
>>>
>>>Thanks in advance
>>>
>>>Jan WIllem
>>
>>
>>The problem is the way the accumulated CPU time is updated. The typical
>>operating system updates the accumulated CPU time at several points:
>>
>>1. When the process is interrupted and preempted by another process.
>>
>>2. When the time quantum for the current process runs out.
>>
>>If you are running by yourself, the latter is the most common, and that
>>means that the accumulated CPU time will not increase smoothly, but will
>>rather jump in increments. A typical scheduling quantum is 200ms, so that
>>the cpu time will jump in fairly big steps. If what you are timing takes
>>less than 200ms, you might get 0 or you might get 200, depending on when you
>>happen to sample.
>>
>>A better scheme is to either (a) use the wall clock time in microseconds if
>>you can get to it; (b) use the CPU hardware performance counter register that
>>is incremented once each CPU clock cycle. Either is better than using the
>>CPU time, which I assume you are doing to see the variance youi are getting.
>
>Thank you for your reply, but can you be more specific how to implement this. Or
>did you do this in Crafty in which case i can look it up in the source code.
>
>Jan Willem
To get accurate elapsed time in unix, I use gettimeofday() which returns
time accurate to microseconds, maybe. notice I say maybe, because the PC
hardware clock is not accurate to microseconds, rather it has a roughly
20ms resolution. Therefore, you need something else. The hardware performance
counter register is the best bet as it is accurate to the clock-cycle level
which is very good...
You will discover that using most any "timer" whether it be cpu or elapsed,
is subject to significant quantization errors due to the timer update interval
not being particularly fast, compared to the clock speed of the basic CPU. IE
good real-time-clock intervals for unix boxes hit 10ms per tick, or 100 ticks
per second. 10ms covers a _lot_ of instruction cycles and makes measuring 20-50
instruction intervals impossible. Even 50,000 instruction intervals are not
measurable at that resolution.
That is why Intel added the hardware performance counter register... it gets
incremented once each clock cycle...
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.