Hash cache

[Joost Buijs]

Well, I measured the average number of CPU cycles for my evaluation function and a TT probe with 2 different TT sizes, one of 1 MB. and one of 1024 MB.
The TT uses 16 byte entry's and 4 buckets per key.
I used a 7 ply search on the 1500 positions from STS and averaged the result.
Before loading each position the pawn-table and TT are cleared.

The result is as follows:

Code: Select all

Evaluation including pawn-table probe 714 cycles.
1 MB. TT probe 46 cycles.
1024 MB. TT probe 60 cycles.

This means that calling the evaluation function before a TT probe really is a waste of time.

[Joost Buijs]

These results are for a Haswell processor with 4 channel DDR 4.
It is possible that probing the TT on an AMD or older Intel processor will tell a different story.

[Joost Buijs]

Still difficult to tell whether it is a waste of time or not.
It depends also upon the hit ratio versus the stand pat ratio.

[hgm]

Well, if the eval takes that long my guess is that it would indeed be better to first probe TT.

[Joost Buijs]

Well, if the eval takes that long my guess is that it would indeed be better to first probe TT.

It is on my todo list to check what performs best.

Unfortunately it is a bit difficult to change it in an elegant way.
I have to hack it in, and that is something I don't like.
It has everything to do with researching a position and not wanting to call the evaluation function several times in a row for the same position.
I can use a flag (very ugly) or add an evaluation cache to avoid this problem.
Another option is to probe the TT right after the do-move, in that case I have to change the layout of the search somewhat.

[hgm]

You could even probe the TT before do-move. No reason to make the move if you would cut off on a TT hit.

[Aleks Peshkov]

It is difficult to get the hash value of a new position without doing a move.

[hgm]

I never noticed that. I always start calculating the hash key, to use it for repetition detection. If the move is a repetition, then making it is a waste of time. (And probing the TT would also be a waste of time.)

Normally the hash-key update only requires the from-square, to-square, and what is on them, which can be known from the current position. No reason to change anything on the board or in the piece list. Special moves are flagged in the move list, (I usually use an invalid to-square for those), so they are easily detected, and cause a move-type-dependent modification of the normal key (which you could or instance tabulate as a function of the signalling to-square value).

E.g.

Code: Select all

int to = TOSQR(move);
int from = FROMSQR(move);
int piece = board[from];
if(to >= 64) { // invalid to-square
  hashKey ^= specialKeys[to-64];
  to = toSquares[to-64];
}
hashKey ^= zobrist[piece][from] ^ zobrist[piece][to] ^ zobrist[board[to]][to];

[Joost Buijs]

True, you can calculate the hash and probe the TT before doing the move.
It will make the search less structured though.
Moving the hash calculation out of the do-move will probably cost you some extra cycles as well.
I doubt that you will gain much, only in case of a TT hit there is a redundant do-move undo-move pair that wastes some time.

[Joost Buijs]

And in case of a repetition of course.