Missing time limit on search

[peso]

For valid testing of relative strength of two versions, you need to control search by time spent, not by search depth. A handfuld of games with 1 second per move is an ok indicator. This is the only way to truly know if a change was an improvement or not.

For example, compare the strength of a fast but weak evaluation function versus a slow but strong evaluation function. Or, when you compare forward pruning techniques that increase depth - big search depth is not always an indicator of strength.

If you add a stop criteria tested during search, you can utilize time allocated very precisely. You need to be careful to implement the stop test very efficiently.

When the stop-test is working, next step should be to add iterative deepening. This works very efficiently, if you have transposition tables (which you already have).

[Cotix]

I'm not sure how useful a timelimit is going to be without iterative deepening. Stopping half way the depth-first search is not going to be representative, as evaluating one half of the tree might result in a wildly different result than evaluating the other half.

[peso]

Correct. It is only half the solution.

[Cotix]

I just implement both the timelimit as the iterative deepening. The iterative deepening should probably do some smart sorting, but for now this suffices.