need your advice on clock()

[Pierre-Marie Baty]

clock() does not return unsigned longs, hence the rollover is fixed to LONG_MAX and can't be changed. It's the RETURN TYPE of the clock() function which determines the rollover, not the capacity of the variable I put it in.

And in this function the type "double" was used only to provide a greater floating-point computation accuracy, but this extra precision is not needed in the return type, since converting the results to float do not truncate any data at all. The precision was only needed during the computations.

gotcha. it's too bad clock() doesn't take advantage of the full range of longs.

[botmeister]

Originally Posted by dav

one other thing - is current_clock, etc. ever negative? it doesn't seem so, therefore why not make those values unsigned longs instead of just longs, and thus get 2^32-1 clock ticks till rollover instead of 2^31-1?

second thing, the return value should probably be a double if you are passing back time_in_seconds, which is a double.

As PMB says, clock() returns a signed long. The only reason for it that I can see, is that it will return -1 if the clock() result is unavailable for whatever reason. Seems silly when they could of had it start from 1 to 2^32-1 and used 0 as the invalid result, or used another method.

In any case, I think the function we now have (once float is replaced with double and all optimizations are put in place) is about as good as it can get.

*edit*

I guess we should have the function check for the -1 result if clock() ever returned it

[botmeister]

I'm having concerns about the accuracy of clock(). It may not have enough resolution to do adequate timings in some cases even for a bot. I'll report what I find here once I'm done testing.

BTW to test the ProcessTime function, you don't have to wait 28 days for a rollover, instead create a function called clock_test() and replace clock() with it as shown here

long clock_test(void)
{
static long counter = LONG_MAX-2; // set this to rollover in 2 clock ticks;
counter++;
if (counter < 0) counter = 0; // reset to zero on rollover;
return counter;
}

Now run a simulted timing test to see if ProcessTime deals with the rollover properly.

start = ProcessTime(); // clock_test()= LONG_MAX-1
stop = ProcessTime(); // clock_test()= LONG_MAX 
 
diff = stop - start; // diff should = 0.001 seconds
 
stop = ProcessTime(); // clock_test()= 0 due to rollover
 
diff = stop - start; // diff should = 0.002 seconds

*update*

On my computer, tests show that clock() increments in units of 10 ticks. This means the actual resolution is in units of 0.01 second instead of 0.001 second. You can still time events which take more time than 1/100th of a second, but there are many timing applications where you'll need more resolution. For example, you cannot use clock() to accurately time the duration of frames (100 FPS = 0.01 seconds per frame which is at the resolution limit).

[@$3.1415rin]

already tried using this rdtsc stuff instead ? ok, you'll get the absolute time and not the time of your process, but maybe one could do some filtering ...

why do you need a better timebase than the one of HL ? are the bots running better if calculating your own time ? I always thought that if the bot and the engine are based on the same time, that shouldnt make problem ... but looks like I'm wrong here hl is getting stranger and stranger ... but hey, that was always the case, right ?

[botmeister]

Originally Posted by @$3.1415rin

already tried using this rdtsc stuff instead ? ok, you'll get the absolute time and not the time of your process, but maybe one could do some filtering ...

I almost forgot about rdtsc, thanks for reminding us!

I have not used rdtsc because I am looking for a generic method of timing events. Perhaps I'm wrong, but the rdtsc instruction appears to be cpu specific and not generic from what I read here
http://www.scl.ameslab.gov/Projects/Rabbit/menu4.html

I suppose you could write code to take into account all processors, but that's a lot of effort, and testing it requies access to each cpu type.

note that I'm not actually interested in process time, but in real time, so the performance counter is actually better than the process clock - for me anyway.

why do you need a better timebase than the one of HL ? are the bots running better if calculating your own time ? I always thought that if the bot and the engine are based on the same time, that shouldnt make problem ... but looks like I'm wrong here hl is getting stranger and stranger ... but hey, that was always the case, right ?

The idea is to create code the is independant of the game engine as much as possible. I think we discussed the reasons why in another thread somewhere, but one reason is ownership (I want to actually own some of the code that I write, not give it away to companies like Valve as per their license agreement), the other is to achieve portability from one game system to another. These are BIG reasons imo to isolate the SDK and the make use of as little of the engine calls as possible.

[botmeister]

During my port of mEAn to linux g++ 3.x I discovered that clock() under linux works differently than under windows and returns the processor time (in ticks) used by the calling process. Under windows, clock() instead returns the time (in ticks) that has elapsed since the calling process was invoked.

So, under linux, clock() will tell you how much cpu time the process has used, but under windows clock() will tell you how much time has gone by since the process was first executed. These are two very different numbers, and under linux the use of clock is no good for replacing pfnTime( ).

[@$3.1415rin]

clock under windows < me also is only accurate to apprx 100ms I think, cause that's the timebase it's working with. xp / 2k / nt use 10ms, though they are still based on the timer on your mainboard ( system timer is at 1193182 Hz ) and not on the cpu clock.