So if you can store move/depth/lock in a single atomic entry, would you still need the lockless hashing? The only other thing in the table is the score/bound type.bob wrote: Lockless hashing is NOT about "Elo". It is about correctness in a threaded search, where a bad move (or other information) could cause a program to crash. If your program is immune to crashes caused by a bogus hash table best move, this won't provide any measurable gain whatsoever. Same applies to lockless pawn hashing as well.
Of course that assumes you can write those three entries together atomically, which may not be the case in practice (I haven't checked).
Of course the program can still encounter a false hash hit with a bogus move. This happens rarely, but personally I find a program that is known to crash occasionally during normal operation inelegant. However, if you do accept this possibility, you can actually gain a bit by storing whether the position is "in check" or not, and skip that test (which can be done efficiently, but is still relatively slow).