Correct me if I'm wrong, but I think that lock-less hashing is not guaranteed to be correct for perft counts. In regular searches, almost all (and rare to begin with) read/write races on individual hash entries are filtered out by the alpha-beta mechanism, but for perft any error will certainly propagate up to the root count. Nevertheless, it appears that you got away with it (I also got away with hard hash collissions with my perft(21) confirmation and perft(22) computation, but I wonder how lucky I was then). I think having a single hash table per core is the only way to guarantee correctness (barring memory errors of course).
Hi Rein, I am currently using hash records with 64-bit signatures but have not encountered a problematic type-1 error (key collision) yet as my figures agree with Aart. Aart said in his other post he uses collision-free hash tables, which is the better way.
But the lock-less hashing method I use does not make this situation better or worse. Type-1 collisions can happen in single threaded or multi threaded (+ lock-less hash) perft apps and can ruin the results either way.
you can avoid type-1 collisions altogether by storing the whole position in the hash table, which can be done in 96 bits without any fancy compression (97 if you need to store the side to move also).