Closed BimmerBass closed 3 years ago
BimmerBass
commented
3 years ago After having tested Loki with 2 threads against the single-threaded version, I haven't noticed any changes. The former is still considerably stronger.
Despite of this, a working lockless hashing algorithm will have to be implemented in v4.0 since the hash-move needs to be legal if it is to be searched immediately with staged move generation.
BimmerBass
commented
3 years ago Edit: Another idea instead of having a shared lockless hash table, is to just make the entry size <= 64 bits. This will of course only work for 64-bit systems, so a solution still needs to be found for 32-bit.
BimmerBass
commented
3 years ago The final solution is in the tt-remake branch. It consists of having different entries to the transposition table for different architectures. For a 64-bit system, I use a 64-bit entry which ensures that no two threads will write to it simultaneously. For 32-bit systems I use a lock-less hashing algorithm to make sure corrupted entries doesn't get used. This unfortunately means that for 32-bit systems, the entry size is double that of 64-bit ones (since we need another 64-bits for the key), but this will be the final solution.
Regarding the staged move generation and tt move, a pseudo-legal-check method has been implemented to combat this issue.
BimmerBass
commented
3 years ago The issue has now been fixed as of #27
In the search-eval-rework-branch that I'm working on at the moment, I noticed that the hashtable Loki currently uses only gives around 16 elo of performance compared to bare alphabeta (with move ordering and quiescence) whereas a one without the lockless hashing mechanism gives ~60. Both were tested with 64MB.
Therefore, I have disabled it, but this doesn't seem to be sufficient of Loki is to be run in a multithreaded way. I will have to test the Lazy SMP algorithm with this table, but it seems inevitable that I'll have to go back and change the hashtable again.