clock_gettime extremely slow

[Ras]

I used to call ftime() for getting the time in the search. That function is deprecated under Linux, and in the Android NDK, it is not even available. So I went for the recommended clock_gettime(CLOCK_MONOTONIC, &timebuffer); call.

Now this change reduced my NPS by 40%, and the time needed to reach a certain depth in a simple test position went up by a factor of 3.5.

It is really this change alone since when I took it back, things were back to normal. Tested under Win7-x64 with MingW.

Is this normal? What time function do you recommend? Should I stay with ftime under Windows and Linux? What should I use on Android? Or is this a MingW problem?

[kbhearn]

How often are you calling the function?

[Ras]

It's called in every node in the loop that goes over the available loops. Looks like that could be optimised to be checked only before that loop?

But still, why is one time function so extremely different from the other? From what I know, both functions should be about equal in terms of burnt cycles.

[mjlef]

It's called in every node in the loop that goes over the available loops. Looks like that could be optimised to be checked only before that loop?

But still, why is one time function so extremely different from the other? From what I know, both functions should be about equal in terms of burnt cycles.

Due to this overhead, most programs only check time ever XXXX nodes. You want to pick a XXXX that is takes about 1 millisecond or a bit less, since UCI times are all in milliseconds. So if you program does say 1 millions nodes per second, then polling time every 1000 nodes should work.

[Ras]

How often are you calling the function?

Just changed the code a bit and moved the time call outside the loop. Actually, it will be called in the next depth level anyway - but not in the leafs.

Oh, and I had even been calling that in QS - I forgot to take it out when porting the engine back from the bare metal microcontroller where that call is just reading an integer.

Now things are more friendly: clock_gettime slows down the NPS by only 6%, and the time to depth raises also only by 6%.

Next idea is Mark's suggestion to only make the actual call every so many nodes.

[Ras]

So if you program does say 1 millions nodes per second, then polling time every 1000 nodes should work.

Good idea - would have to be calibrated to the NPS (depending on position and hardware), but these data are available anyway.

[cdani]

Andscacs calculates nodes per ms during search, and decides depending on the remaining time if it polls the time only once in 100ms or often.

[hgm]

If you want to do it in an advanced way, you could just schedule an event at the time you want to alter the behavior (e.g. stop unconditionally, stop when the root score is above a certain level, or think unconditionally), and let the handler routine set the appropriate flags that the search tests to implement that behavior.

[Ras]

So if you program does say 1 millions nodes per second, then polling time every 1000 nodes should work.

Just implemented that trick. I initialise the NPS_1ms to 0 and always check whether more nodes have been calculated since the last time than that. So during the first one or two ms, the value may be too low, but since I'm calibrating the value against absolute nodes vs. absolute time, that quickly becomes accurate.

No difference anymore between the two time functions, and I get a nice 10% speedup compared to the version where I moved the time check outside the node loop.

thanks folks!

[Ras]

If you want to do it in an advanced way

Sounds like a lot of platform dependent stuff. However, the code that interfaces threaded stdin scanning with the search is portable - if only because it's a total hack on every platform.