mcostalba wrote:You could simply check (ss+1)->tbScore and if, for instance it is a TB loss then you can safely return a win, without continuing searching, so although you didn't TB probe at the beginning of the search(), it does not take a lot, in case of a winning position, to early cut-off the search, thanks to the TB score stored in the stack of the inner nodes.
Does this scheme seems reasonable?
You would have to be lucky to play the winning move first.
If instead you probed immediately, you would have known the position is won and you can return immediately (if beta < TB win). This avoids having to probe (and search etc.) ony ply below (and one ply further below, etc.).
Hint: if probing the current position does not give a TB result, then probing the ply below will not give a TB result either. Unless you play a capture that brings you in the TBs.
If the current position can be resolved by a TB probe (which is the case if +/- TB win is outside (alpha, beta)), it is not reasonable to instead recursively search and probe.
Only if you want to know more than win/draw/loss, so only if beta > TBwin (or alpha < -TBwin) does it make sense to search on. Even then, it makes a lot of sense to probe first, because maybe you are looking for a win but the position is drawn or lost. (And I think that in this case one would like to "correct" the result returned to the parent in case the subtree search does not return a value bigger than TB win.)
Of course instead of TB win you could return VALUE_KNOWN_WIN. But not correcting for distance to root might result in the search not making progress. Maybe this danger is very small for SF, I don't know.