Lock-less transposition table implementation in Crafty

[jromang]

I'm trying to experiment the Lock-less transposition table idea from Dr Hyatt's paper ; but after looking the source code from crafty 22.1, it seems this isn't implemented in crafty....I can't see a XOR'ed word1 anywhere

Code: Select all

temp_hashkey = (wtm) ? HashKey : ~HashKey;
  htable = trans_ref + ((int) temp_hashkey & hash_mask);
  word1 = htable->prefer.word1;
  word2 = htable->prefer.word2;
  if (word2 == temp_hashkey) ....

Do I miss something ? How is the concurrent transposition table access issue solved in crafty ?

[Harald Johnsen]

On bob's site your find an experiment that shows that hash errors have no real impact on the search. So there is no need to handle an error free hash table update (iirc).

HJ.

[mathmoi]

On bob's site your find an experiment that shows that hash errors have no real impact on the search. So there is no need to handle an error free hash table update (iirc).

HJ.

I can't find this experiment, can you link to it please?

MP

[Gerd Isenberg]

On bob's site your find an experiment that shows that hash errors have no real impact on the search. So there is no need to handle an error free hash table update (iirc).

HJ.

I can't find this experiment, can you link to it please?

MP

http://www.cis.uab.edu/hyatt/collisions.html

[mathmoi]

Thanks

[jromang]

Thanks for the answers

[bob]

I'm trying to experiment the Lock-less transposition table idea from Dr Hyatt's paper ; but after looking the source code from crafty 22.1, it seems this isn't implemented in crafty....I can't see a XOR'ed word1 anywhere

Code: Select all

temp_hashkey = (wtm) ? HashKey : ~HashKey;
  htable = trans_ref + ((int) temp_hashkey & hash_mask);
  word1 = htable->prefer.word1;
  word2 = htable->prefer.word2;
  if (word2 == temp_hashkey) ....

Do I miss something ? How is the concurrent transposition table access issue solved in crafty ?

It was removed. I had to validity-check the moves from the hash table anyway as a bad move can completely crash the program. And after the hashing study I did a couple of years ago, it was pretty obvious that the very rare errors caused by the corrupted hash entry issue was not going to impact the search quality at all, and avoiding the extra XOR's made it a bit faster.