ZirconiumX wrote:FFT is straightforward (in the sense that there is no recursion etc) math. Many things can do math, and a GPU can do math in parallel.
Tree search is very complex math, which would require a lot of time attempting to formulate a layout for a chess program.
You'd also have to do a lot of very awkward things, like for maximum performance use DMA, which requires being root, and fiddling about.
It's a lot of effort. If you can manage it, good job, but do not expect it to be easy.
Matthew:out
I conceded earlier that perft analysis might not be as good a fit as other problems the pi can tackle, but it will be fun to tackle them and see what the results are going to be. Now, if I were going to build the pi cluster just for chess analysis I don't think there is a good argument there.
What I do find interesting is that the pi community is coming up with some good use for the GPU and some of the results are a bit shocking compared to what people originally thought those results might be.
As of about an hour ago, the project has calculated 215,344 perft(7) results. This is a big 1/448 of the work needed.
Only the very last work unit is complete. It may be of interest for those wish to verify some of the results so far, and it may also be useful for those tuning their own Monte Carlo perft() estimators.
sje wrote:As of about an hour ago, the project has calculated 215,344 perft(7) results. This is a big 1/448 of the work needed.
Only the very last work unit is complete. It may be of interest for those wish to verify some of the results so far, and it may also be useful for those tuning their own Monte Carlo perft() estimators.
Ajedrecista wrote:I have just checked these 68 values of perft(7) with JetChess and all the results match.
Good. I hope you can keep up; there are now 231,111 perft(7) results. The count is increasing by about one every two seconds giving a total calculation time estimate of about 6.1 years.
Ajedrecista wrote:I have just checked these 68 values of perft(7) with JetChess and all the results match.
Good. I hope you can keep up; there are now 231,111 perft(7) results. The count is increasing by about one every two seconds giving a total calculation time estimate of about 6.1 years.
Sorry but it is impossible: I copied and pasted manually each FEN string into JetChess (copy-paste, compute; copy-paste, compute; etc.) and the time of calculation oscillated between 35 and 90 seconds for each position, depending on the amount of leaf nodes. I would say that an average time was 50 seconds for many positions, so it is clearly impractical for me. I did it because there were only 68 positions but this task took me a little more than an hour.
Now at 288,817 perft(7) calculations; this is about 1/334th of the 96,400,068 needed. Current throughput is about 40,000 perft(7) calculations per day, or one work unit every 2½ days.
I have a couple more machines I could throw at the problem, but they are too old and slow to be worth the cost of electricity.
Motivated by a power outage yesterday, I have provided a more automated recovery process. A better approach would be to implement a client/server model with a UPS protecting the server machine.
I really need to write an OpenCL perft() routine. That would much less expensive than buying a truck load of new computers.
It would be very helpful if others could assist with the work unit processing by doing verification or original calculation. Do you some spare machine time? Do you have a reliable perft program? Do you have electricity?
And as soon as we have a verified perft(14), we can start work on perft(15) (ca. 2*10^21 = two sextillion). But if you want to start work on perft(15) right away, then you can use the work units and run perft(8) and a multiplication on each to get the result.
Sadly, due to parental limits, I'd only be able to work on and off, which is slightly irritating. I'll try my best. Got any particular recommendations for fast perft programs?
sje wrote:Now at 288,817 perft(7) calculations; this is about 1/334th of the 96,400,068 needed. Current throughput is about 40,000 perft(7) calculations per day, or one work unit every 2½ days.
I have a couple more machines I could throw at the problem, but they are too old and slow to be worth the cost of electricity.
Motivated by a power outage yesterday, I have provided a more automated recovery process. A better approach would be to implement a client/server model with a UPS protecting the server machine.
I really need to write an OpenCL perft() routine. That would much less expensive than buying a truck load of new computers.
It would be very helpful if others could assist with the work unit processing by doing verification or original calculation. Do you some spare machine time? Do you have a reliable perft program? Do you have electricity?
And as soon as we have a verified perft(14), we can start work on perft(15) (ca. 2*10^21 = two sextillion). But if you want to start work on perft(15) right away, then you can use the work units and run perft(8) and a multiplication on each to get the result.
Why not CUDA? It's a good stopgap, and you won't have to do any work.
ZirconiumX wrote:Got any particular recommendations for fast perft programs?
If not, I'll just use Stockfish.
Crafty has a perft command (that's how perft got its name).
To do the calculations for an entire work unit, there really should be some form of automation that doesn't involve manually handling each of the 100,000 records. So at least some programming is required, although not very much. Maybe someone could add an "autoperft" command to Crafty or Stockfish and connect it to a pair of formatted I/O routines and the existing perft code. For best results, the perft code should employ bulk counting and transposition table assistance.
