Win scores in the TT causing problems

[xsadar]

2) Once a mate has been returned by a search, clear out any mate scores in the TT after each subsequent search.

I'm not understanding method #2. Why would you want to do that? What does it accomplish? It sounds to me like you're just throwing away the most useful information you have, and I don't see what it's even supposed to give you.

The goal is to terminate the search once a mate is found. This is desirable for at least the following reasons.
1) The program responds quicker when there is an obvious mate and therefore does not appear "dumb".
2) When setting the thinking time to "forever", the program will terminate when a mate is seen as opposed to stopping when it has exhaustively searched all paths (which could take a very long time).
3) During self play, the program should not oscillate between "Mate in 10", "Mate in 12", "Mate in 11", "Mate in 12" etc...
Note, my program is for recreational, not tournament play.

My program will terminate an iterative deepening search when it sees a mate. Since the program currently performs a full width search to a fixed depth, the first time it sees a mate, it will be minimal and the search will immediately terminate as expected. Call this "Mate in N"

The problem arises during the next search. Note I do not clear out the hash between moves. What can happen is that a shallow search finds a mate, but the mate is "Mate in N+d" where d is a number greater than 0. At shallow depths there is no guarantee of finding the "Mate in N" for a number of reasons such as the "optimal" hash entries happened to be overwritten. So we see the mate in N+d, report it and thereby oscillate.

One way to overcome this is via #1. If we know that we can mate in N on the last move, then we should search to at least N-2 the next time around.

#2 just sidesteps the problem by effectively saying "mate entries in the hash cause problems, so remove them". Admittedly, not the best solution (brute force), but it does work. Also, since the trees are smaller at the end game, ignoring them may not have much impact. I do agree with yout that it is better not to throw away information if that can be avoided.

-- Greg

OK. Sorry. I misunderstood what you were doing with #2. I can see how that could help some, but it seems to me that it still may not work in every situation. And even if it does, I agree with Bob: it's entirely the wrong way to go about it.

[gschmidt]

OK. Sorry. I misunderstood what you were doing with #2. I can see how that could help some, but it seems to me that it still may not work in every situation. And even if it does, I agree with Bob: it's entirely the wrong way to go about it.

Actually, it does work because the root level search will never see a misleading mate score in the hash. I think we all agree though, it's not the correct solution. The fact that it does work helps confirm the underlying problem.

-- Greg

[gschmidt]

I tried running crafty under AMD's CodeAnalyst and it claimed that crafty spent almost 5% of its time on the single line that read a TT entry.

That seems counterintuitive to me. Given a Zobrist key and a flat (non-chaining) hash, I would think that indexing into the hash, checking the hashlock and retrieving a value would only be a few instructions. Is it the non-localized memory fetch time we're dealing with here?

-- Greg

[jwes]

I tried running crafty under AMD's CodeAnalyst and it claimed that crafty spent almost 5% of its time on the single line that read a TT entry.

That seems counterintuitive to me. Given a Zobrist key and a flat (non-chaining) hash, I would think that indexing into the hash, checking the hashlock and retrieving a value would only be a few instructions. Is it the non-localized memory fetch time we're dealing with here?

It is generally a cache miss and frequently a TLB miss, which can take hundreds of cycles.

[bob]

I tried running crafty under AMD's CodeAnalyst and it claimed that crafty spent almost 5% of its time on the single line that read a TT entry.

That seems counterintuitive to me. Given a Zobrist key and a flat (non-chaining) hash, I would think that indexing into the hash, checking the hashlock and retrieving a value would only be a few instructions. Is it the non-localized memory fetch time we're dealing with here?

-- Greg

almost certainly...