Perft(13), the result

Discussion of chess software programming and technical issues.

Moderator: Ras

User avatar
sje
Posts: 4675
Joined: Mon Mar 13, 2006 7:43 pm

Re: Perft(13), the result

Post by sje »

The result isn't very large. When printed to paper, it's only about five centimeters long. :D
User avatar
sje
Posts: 4675
Joined: Mon Mar 13, 2006 7:43 pm

Some observations

Post by sje »

Some observations:

1) The effective node frequency was about 54 GHz.

2) The effective node time was about 18 picoseconds.

3) My program Symbolic which did the run is a chess program and not a perft program. The only concession to doing perft is the use of a 120 bit hash. The rest of the program behaves mostly like a real search is running, so there are many calculations performed which are unneeded for path counting.

4) Getting a correct result was far more important than getting a fast result, so absolutely no overclocking was used. Further, an extra high capacity heat sink and fan were part of the system, just for a little more confidence.

5) I was not surprised that the program produced the correct answer, as the same program and machine had done all other perft calculations correctly including perft(12). The only real danger was the possibility of cosmic ray interference (seriously) causing a bit flip which would go undetected because of not having ECC memory.

6) Having a UPS might have shortened the total running time by two months or more.

7) Perft(14) is close to 70 quintillion and will break 64 bit arithmetic. Can it be done? Sure. Am I going to do it any time soon, if ever? Rather doubtful, to say the least.
ibid
Posts: 89
Joined: Mon Jun 13, 2011 12:09 pm

Re: Some observations

Post by ibid »

Congratulations! And you don't know how glad I am the numbers matched. :)
sje wrote:5) I was not surprised that the program produced the correct answer, as the same program and machine had done all other perft calculations correctly including perft(12). The only real danger was the possibility of cosmic ray interference (seriously) causing a bit flip which would go undetected because of not having ECC memory.
That kind of thing was my concern also -- some rare unpredicatable hardware issue -- especially on such a long running program. I wish ECC memory were more available for consumer machines.
sje wrote:6) Having a UPS might have shortened the total running time by two months or more.
It's a bit late now, but... you might consider dumping the entire hash table to disk once a day or something to reduce the impact of a restart.
sje wrote:7) Perft(14) is close to 70 quintillion and will break 64 bit arithmetic. Can it be done? Sure. Am I going to do it any time soon, if ever? Rather doubtful, to say the least.
Even for my program, which is stripped down to the bare essentials to produce just the one final number, I estimate 18 months or so to compute perft(14). Too much for me. Then again, perft(12) was a lot of work 6 years ago... so I will likely revisit the idea of a perft(14) again... perhaps in 2018. :)

-paul
Rein Halbersma
Posts: 749
Joined: Tue May 22, 2007 11:13 am

Re: Some observations

Post by Rein Halbersma »

ibid wrote:
sje wrote:7) Perft(14) is close to 70 quintillion and will break 64 bit arithmetic. Can it be done? Sure. Am I going to do it any time soon, if ever? Rather doubtful, to say the least.
Even for my program, which is stripped down to the bare essentials to produce just the one final number, I estimate 18 months or so to compute perft(14). Too much for me. Then again, perft(12) was a lot of work 6 years ago... so I will likely revisit the idea of a perft(14) again... perhaps in 2018. :)

-paul
Given that checkers-perft(28) is an order of magnitude larger than chess-perft(13), and given that you quickly computed checkers-perft(28), how come chess-perft(14) would take 18 months? Is the number of unique positions at depth=10/11 in chess so much larger than doing the same at depth 22/23 in checkers? Or is saving these unique positions taking much more space?
rbarreira
Posts: 900
Joined: Tue Apr 27, 2010 3:48 pm

Re: Some observations

Post by rbarreira »

sje wrote: 3) My program Symbolic which did the run is a chess program and not a perft program. The only concession to doing perft is the use of a 120 bit hash. The rest of the program behaves mostly like a real search is running, so there are many calculations performed which are unneeded for path counting.
How much impact do you think this had on the calculation time?
plattyaj
Posts: 9
Joined: Mon Jul 09, 2012 2:54 pm

Re: Some observations

Post by plattyaj »

sje wrote:7) Perft(14) is close to 70 quintillion and will break 64 bit arithmetic. Can it be done? Sure. Am I going to do it any time soon, if ever? Rather doubtful, to say the least.
Well, all you need to do is find another 19 people and they can each do perft(13) from one of the initial moves. ;)

Congrats.
Author of Schola (RIP); working on NCE.
User avatar
JuLieN
Posts: 2949
Joined: Mon May 05, 2008 12:16 pm
Location: Bordeaux (France)
Full name: Julien Marcel

Re: Some observations

Post by JuLieN »

plattyaj wrote:
sje wrote:7) Perft(14) is close to 70 quintillion and will break 64 bit arithmetic. Can it be done? Sure. Am I going to do it any time soon, if ever? Rather doubtful, to say the least.
Well, all you need to do is find another 19 people and they can each do perft(13) from one of the initial moves. ;)

Congrats.
The future of perft calculations is an automatized collaborative effort à la SETI. We should design a server/client software that would automatically send job lots to local clients ("compute perft 10 starting from this FEN position")...

What do you guys think ?
"The only good bug is a dead bug." (Don Dailey)
[Blog: http://tinyurl.com/predateur ] [Facebook: http://tinyurl.com/fbpredateur ] [MacEngines: http://tinyurl.com/macengines ]
User avatar
sje
Posts: 4675
Joined: Mon Mar 13, 2006 7:43 pm

Re: Some observations

Post by sje »

rbarreira wrote:
sje wrote: 3) My program Symbolic which did the run is a chess program and not a perft program. The only concession to doing perft is the use of a 120 bit hash. The rest of the program behaves mostly like a real search is running, so there are many calculations performed which are unneeded for path counting.
How much impact do you think this had on the calculation time?
Hard to say; perhaps the program is taking twice as long as would a more streamlined set of minimalist routines. There's a lot of incremental updating which has nothing to do with counting paths. But to take it out would mean lots of debug time and no assurance that no new bugs were introduced.
mar
Posts: 2654
Joined: Fri Nov 26, 2010 2:00 pm
Location: Czech Republic
Full name: Martin Sedlak

Re: Some observations

Post by mar »

JuLieN wrote: The future of perft calculations is an automatized collaborative effort à la SETI. We should design a server/client software that would automatically send job lots to local clients ("compute perft 10 starting from this FEN position")...

What do you guys think ?
Good idea if you pay my electricity bill :wink:
No seriously I think it's a very good idea, the only problem IMHO is how to convince enough people to participate. Hype perhaps.

And of course (a bit late) congratulations to Steven.
User avatar
sje
Posts: 4675
Joined: Mon Mar 13, 2006 7:43 pm

For the wiki, mostly

Post by sje »

If anyone is interested in the draft 11 and draft 12 position and counts, it might be a good idea to grab a copy now. (I'm thinking about the chess wiki in particular.)

https://dl.dropbox.com/u/31633927/Perft/Perft13/draft12
https://dl.dropbox.com/u/31633927/Perft/Perft13/draft11

Also, a copy of https://dl.dropbox.com/u/31633927/Perft/InitialPosition would be good for the chess wiki.

If anyone wants to challenge my results, simply pick the draft 11 position/count you think is faulty and we can drill down to settle any disagreements.