International draughts tournament 2024

[Krzysztof Grzelak]

Round 8 results:

Edeon Sport 5.4.312 - Scan 3.1 1-1
Kingsrow 1.63 - Dragon Pro 4.6.2 1-1
Ares 1.63d - Truus voor Windows 1.0 1-1
Damage 16.1 - Maximus 2.02 1-1
Moby Dam (Jul 12 2023) - Sjende Blyn (Febuary 21th 2024) 1-1
Tornado 7.20r - Horizon 5.0 0-2
Flits 3.02 - Cerberus 2.3 2-0
Dream 3.X.4 - GWD 3.7 0-2
Plus 500 6.55.1.10 - TD King 2020 0-2

Round 9 - I will inform the forum when it will take place.

Ares 1.63d - Scan 3.1
Dragon Pro 4.6.2 - Truus voor Windows 1.0
Moby Dam (Jul 12 2023) - Kingsrow 1.63
Damage 16.1 - Flits 3.02
Horizon 5.0 - GWD 3.7
Tornado 7.20r - Sjende Blyn (Febuary 21th 2024)
Cerberus 2.3 - Edeon Sport 5.4.312
Maximus 2.02 - Plus 500 6.55.1.10
TD King 2020 - Dream 3.X.4

For more details about the tournament, please visit the website https://www.draughtsprograms.eu/SwissTo ... eGames.php and
https://results.fmjd.org/tournaments/2024/f_51/

[Joost Buijs]

Hi Krzysztof,

Thank you for organizing this event! Tournaments like this are always nice to check how experimental stuff works out.

Very early this morning I found the worst bug ever in Ares.

Ares uses an internal representation with 'ghost squares', these squares run from 0 to 53, unlike most other Draughts programs Ares uses Zobrist hashing, due to an oversight only the Zobrist numbers for square 0 to 49 were initialized. This means when something changes on the last 4 squares of the board the program could pick a wrong entry from it's hash-table, the same applies to it's book too.

The bad thing is that due to this bug many months of experiments are meaningless now and have to be redone, the good thing is that it keeps me off the streets.

Joost

[Jelle Wiersma]

Hi Joost,

Yes, that's a bug, but when fixed, you can still have that two positions have the same hash value and that you end up using wrong information. The chance of two positions having the same hash value is almost 0, but almost 0 is not 0. That's why I also use a lossless comparison of the position being hashed and the position in the hash table.

Jelle

[Ed Gilbert]

Bob Hyatt did some testing on the effects of hash collisions in his chess engine Crafty. His results are published in this short paper: http://craftychess.com/hyatt/collisions.html. His conclusion is that even a gross error rate of 1 in 10,000 positions does not change game outcomes or weaken play. Of course in the case of Joost's bug the error rate is probably much higher.

[Joost Buijs]

"There is always a chance that a collision occurs, but with a good 64-bit hash function like Zobrist, this chance is so small that it will never affect the outcome of the search.

To detect collisions, Ares has the option to store (besides the regular key and data) the whole position in a hash entry. Normally (without bugs), I can let the program run for at least 1 hour without detecting a single collision. With its neural network on a 32-core machine, Ares achieves approximately 150M nodes/sec. A large part of these nodes are quiescence nodes; therefore, the number of hash stores/probes is way lower. Ares doesn't use the hash table for pruning at PV-nodes, making the chance of anything going wrong due to a collision even smaller."

Edit:

Apart from hash collisions, another significant challenge arises in preventing data races when multiple threads access the hashtable concurrently.

Traditional locking mechanisms like Mutexes or critical sections can introduce considerable overhead due to their synchronization operations. Similarly, employing C++ atomics can incur performance penalties, especially with spinlocks for structures larger than 64 bits.

Hyatt-style lock-free hashing, which involves XORing the hashkey with the datafield, presents its own set of issues. Notably, it tends to diminish the effectiveness of hashbits, particularly when the datafield is limited in size.

For hash table entries smaller or equal to 128 bits, an alternative approach is utilizing InterlockedCompareExchange128. Unlike other methods, this option offers better performance without significant drawbacks, albeit limited to X86 machines.

Ares switches between no locking at all for a single thread, Hyatt-style lock-free hashing for a small number of threads, and InterlockedCompareExchange128 for a large number of threads. Lock-free hashing presents too much problems on machines with 32 or 64 cores.

The reason that Ares doesn't use its TT at PV-nodes is that this seems to give better performance with lazy-SMP in combination with a large number of threads. Right now I'm thinking about giving each thread a small private PV-hashtable.

[Krzysztof Grzelak]

The last round of the tournament will take place on 30.03.2024.

[FrankMesander]

Sad news.
Ton Tillemans, who is participating in this tournament with Tdking, passed away unexpectedly last night.

[Krzysztof Grzelak]

New update of the program Ares in the tournament from version 1.63d in to version 1.70.

[Krzysztof Grzelak]

The tournamen " International draughts tournament 2024 " ended with the program winning Scan 3.1 by Fabien Letouzey. I cordially invite you to read the results of the entire tournament on the website https://results.fmjd.org/tournaments/20 ... laces.html. Thanks to the other tournament participants.

Krzysztof

[Jelle Wiersma]

My congratulations to Fabien