Discussion of chess software programming and technical issues.
Moderators: hgm, Harvey Williamson, bob

ankan
 Posts: 52
 Joined: Sun Apr 21, 2013 1:29 pm
 Location: Pune, India

Contact:
Post
by ankan » Fri Sep 09, 2016 8:38 am
Here is the result from the second run (actually two partial runs as the run got interrupted):
Code: Select all
..a2a3 1707945110805813310
..a2a4 2493115507450124588
..b1a3 1988096314966752669
..b1c3 2638654908094170585
..b2b3 2286406377370528139
..b2b4 2297640117530334747
..c2c3 2666334464745721380
..c2c4 3067868595132318179
..d2d3 4459055881158216540
..d2d4 6636612996377425812
..e2e3 7478732807317823667
..e2e4 7614272181524255097
..f2f3 1359948551007941806
..f2f4 1905689484049474095
..g1f3 2585178594020547799
..g1h3 2022544576756325295
..g2g3 2388698250037891063
..g2g4 2050748957027119617
..h2h3 1691016253163166371
..h2h4 2546461593049578478
perft(14): 61885021521585529237
which is same result as what Peter got in 2013
More divided perfts here:
https://github.com/ankanban/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
 Posts: 559
 Joined: Mon Apr 19, 2010 5:07 pm
 Location: Sweden

Contact:
Post
by petero2 » Fri Sep 09, 2016 6:13 pm
ankan wrote:Here is the result from the second run (actually two partial runs as the run got interrupted):
Code: Select all
..a2a3 1707945110805813310
..a2a4 2493115507450124588
..b1a3 1988096314966752669
..b1c3 2638654908094170585
..b2b3 2286406377370528139
..b2b4 2297640117530334747
..c2c3 2666334464745721380
..c2c4 3067868595132318179
..d2d3 4459055881158216540
..d2d4 6636612996377425812
..e2e3 7478732807317823667
..e2e4 7614272181524255097
..f2f3 1359948551007941806
..f2f4 1905689484049474095
..g1f3 2585178594020547799
..g1h3 2022544576756325295
..g2g3 2388698250037891063
..g2g4 2050748957027119617
..h2h3 1691016253163166371
..h2h4 2546461593049578478
perft(14): 61885021521585529237
which is same result as what Peter got in 2013 :)
More divided perfts here:
https://github.com/ankanban/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 subtrees.

petero2
 Posts: 559
 Joined: Mon Apr 19, 2010 5:07 pm
 Location: Sweden

Contact:
Post
by petero2 » Mon Sep 12, 2016 5:48 pm
petero2 wrote:ankan wrote: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/ankanban/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 subtrees.
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
 Posts: 52
 Joined: Sun Apr 21, 2013 1:29 pm
 Location: Pune, India

Contact:
Post
by ankan » Tue Sep 13, 2016 6:30 am
petero2 wrote:
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 subtrees.
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 34 months and I will need to run it at least twice to catch errors due to random bit flips/cosmic rays.