yet another attempt on Perft(14)

[ankan]

Here is the result from the second run (actually two partial runs as the run got interrupted):

Code: Select all

..a2-a3     1707945110805813310
..a2-a4     2493115507450124588
..b1-a3     1988096314966752669
..b1-c3     2638654908094170585
..b2-b3     2286406377370528139
..b2-b4     2297640117530334747
..c2-c3     2666334464745721380
..c2-c4     3067868595132318179
..d2-d3     4459055881158216540
..d2-d4     6636612996377425812
..e2-e3     7478732807317823667
..e2-e4     7614272181524255097
..f2-f3     1359948551007941806
..f2-f4     1905689484049474095
..g1-f3     2585178594020547799
..g1-h3     2022544576756325295
..g2-g3     2388698250037891063
..g2-g4     2050748957027119617
..h2-h3     1691016253163166371
..h2-h4     2546461593049578478

perft(14): 61885021521585529237

which is same result as what Peter got in 2013

More divided perfts here:
https://github.com/ankan-ban/perft_gpu/ ... t?raw=true

The only difference in this run is I used lockless hashing trick for all entries in hash table and the run was performed using a different set of zobrist randoms.

[petero2]

Here is the result from the second run (actually two partial runs as the run got interrupted):

Code: Select all

..a2-a3     1707945110805813310
..a2-a4     2493115507450124588
..b1-a3     1988096314966752669
..b1-c3     2638654908094170585
..b2-b3     2286406377370528139
..b2-b4     2297640117530334747
..c2-c3     2666334464745721380
..c2-c4     3067868595132318179
..d2-d3     4459055881158216540
..d2-d4     6636612996377425812
..e2-e3     7478732807317823667
..e2-e4     7614272181524255097
..f2-f3     1359948551007941806
..f2-f4     1905689484049474095
..g1-f3     2585178594020547799
..g1-h3     2022544576756325295
..g2-g3     2388698250037891063
..g2-g4     2050748957027119617
..h2-h3     1691016253163166371
..h2-h4     2546461593049578478

perft(14): 61885021521585529237

which is same result as what Peter got in 2013 :)

More divided perfts here:
https://github.com/ankan-ban/perft_gpu/ ... t?raw=true

The only difference in this run is I used lockless hashing trick for all entries in hash table and the run was performed using a different set of zobrist randoms.

That is great news!

I compared data from your first and second run and found the following 7 differences after 3 plies:

Code: Select all

moves          run1              run2              diff
b1c3 d7d5 e2e4 36025247586052065 36025247586050529 1536
b1c3 d7d5 h2h4 11701887063591487 11701887063589951 1536
e2e4 d7d5 b1c3 36025247586052065 36025247586050529 1536
e2e4 d7d5 h2h4 34085629580382873 34085629580381337 1536
h2h4 d7d5 b1c3 11701887063591487 11701887063589951 1536
h2h4 d7d5 e2e4 34085629580382873 34085629580381337 1536
h2h4 d7d5 g1h3  9566537572866508  9566537572865484 1024

I don't know if this implies that there were more than one bit flip in the first run, or if the same flipped bit stayed around in the hash table long enough to affect several sub-trees.

[petero2]

Here is the result from the second run (actually two partial runs as the run got interrupted):

Code: Select all

...
perft(14): 61885021521585529237

which is same result as what Peter got in 2013 :)

More divided perfts here:
https://github.com/ankan-ban/perft_gpu/ ... t?raw=true

The only difference in this run is I used lockless hashing trick for all entries in hash table and the run was performed using a different set of zobrist randoms.

That is great news!

I compared data from your first and second run and found the following 7 differences after 3 plies:

Code: Select all

moves          run1              run2              diff
b1c3 d7d5 e2e4 36025247586052065 36025247586050529 1536
b1c3 d7d5 h2h4 11701887063591487 11701887063589951 1536
e2e4 d7d5 b1c3 36025247586052065 36025247586050529 1536
e2e4 d7d5 h2h4 34085629580382873 34085629580381337 1536
h2h4 d7d5 b1c3 11701887063591487 11701887063589951 1536
h2h4 d7d5 e2e4 34085629580382873 34085629580381337 1536
h2h4 d7d5 g1h3  9566537572866508  9566537572865484 1024

I don't know if this implies that there were more than one bit flip in the first run, or if the same flipped bit stayed around in the hash table long enough to affect several sub-trees.

Note that I accidentally swapped "run1" and "run2" in the table headers above.

As an extra sanity check I computed perft 11 for the 4 positions corresponding to the above table. The result was:

Code: Select all

b1c3 d7d5 e2e4: perft(11) = 36025247586052065, t=39055.277 s=9.22417e+11
b1c3 d7d5 h2h4: perft(11) = 11701887063591487, t=23031.932 s=5.08072e+11
e2e4 d7d5 h2h4: perft(11) = 34085629580382873, t=44214.664 s=7.70912e+11
h2h4 d7d5 g1h3: perft(11) =  9566537572866508, t=27567.671 s=3.4702e+11

which agrees with Ankan's results from the second run.

[ankan]

I don't know if this implies that there were more than one bit flip in the first run, or if the same flipped bit stayed around in the hash table long enough to affect several sub-trees.

Impossible to say. I think there is a good probability of same flipped bit staying in the hash table, but we can't be sure.

Thanks for verifying the mismatching counts!

I am planning to start Perft(15) run, but with my current program it will likely take about 3-4 months and I will need to run it at least twice to catch errors due to random bit flips/cosmic rays.