Perft(14)

[sje]

Maybe I shouldn't say too much about perft(14), because I once said that I wasn't interested in doing perft(13) and look at what happened.

It is possible that perft(14) has already been calculated; any of a number of government parallel supercomputers could grind out the result in an afternoon or less. And it would be a good test of distributed integer performance, but it would not be made public.

With consumer level hardware, a distributed approach to perft(14) seems best at this time. But it is a non-trivial task. Consider any number of well known distributed computing projects where the end-user application has had dozens of revisions to squeeze out bugs. Perft(n) cannot admit a single off-by-one error; any bug would mean a restart.

For perft(14), I'd consider generating the 96,400,068 ply seven positions (each with a usage count) and deal these to worker clients with each position getting a draft 7 calculation. Averaging three per second would allow the run to complete in about one year, but without any redundancy checking. Tripling the time (or the processors) would support 2-from-3 majority voting for flagging bad intermediate results.

[lucasart]

Maybe I shouldn't say too much about perft(14), because I once said that I wasn't interested in doing perft(13) and look at what happened.

It is possible that perft(14) has already been calculated; any of a number of government parallel supercomputers could grind out the result in an afternoon or less. And it would be a good test of distributed integer performance, but it would not be made public.

With consumer level hardware, a distributed approach to perft(14) seems best at this time. But it is a non-trivial task. Consider any number of well known distributed computing projects where the end-user application has had dozens of revisions to squeeze out bugs. Perft(n) cannot admit a single off-by-one error; any bug would mean a restart.

For perft(14), I'd consider generating the 96,400,068 ply seven positions (each with a usage count) and deal these to worker clients with each position getting a draft 7 calculation. Averaging three per second would allow the run to complete in about one year, but without any redundancy checking. Tripling the time (or the processors) would support 2-from-3 majority voting for flagging bad intermediate results.

What happenned to your project CookieCat ? Are you going to finish making it a chess engine, or will you go on and explore more perft() ?
I would love to see CookieCat released. Already your perft code written in Pascal is extremely fast, and that's a good sign
Maybe it's time to give perft() a rest and focus on making a chess engine. It's really more fun once you start tuning it, and look how it improves in tournaments against other programs.

[sje]

What happenned to your project CookieCat ? Are you going to finish making it a chess engine, or will you go on and explore more perft() ?
I would love to see CookieCat released. Already your perft code written in Pascal is extremely fast, and that's a good sign
Maybe it's time to give perft() a rest and focus on making a chess engine. It's really more fun once you start tuning it, and look how it improves in tournaments against other programs.

CookieCat can be found at https://dl.dropbox.com/u/31633927/Cooki ... kieCat.pas

Its main goal is to replace the ancient Chess 0.5 program as an example of a chess program written in Pascal. It has the BSD License, so there's a lot of freedom for people to work on it and pass it around.

[JuLieN]

What happenned to your project CookieCat ? Are you going to finish making it a chess engine, or will you go on and explore more perft() ?
I would love to see CookieCat released. Already your perft code written in Pascal is extremely fast, and that's a good sign
Maybe it's time to give perft() a rest and focus on making a chess engine. It's really more fun once you start tuning it, and look how it improves in tournaments against other programs.

CookieCat can be found at https://dl.dropbox.com/u/31633927/Cooki ... kieCat.pas

Its main goal is to replace the ancient Chess 0.5 program as an example of a chess program written in Pascal. It has the BSD License, so there's a lot of freedom for people to work on it and pass it around.

Wow, I'm not the only ches(s)tnut programming a chess engine in Pascal nowadays! Your code is three times bigger than mine and your perft is 3 times faster! I'll add it later to my OSX compiles collection, when I have enough new engines compiled to make an interesting news.

EDIT: rectification: your preft is up to nearly 8 times faster than mine! Impressive!

[sje]

I'm going to neglect perft(n) for a while and work on my Fish80 program (retro-style Intel 8080 chess player) instead.

I might have the perft(13) machine be semi-permanently connected to the ICC, but first I need to open the box and clean out 14 months of cat fur.

[SuneF]

I did a simple distributed version of perft a few years ago, using WCF (SOAP) and entity framework it just took me a day or so to set up.

There are a few issues to solve...

1) Every user should queue up some "work units" locally to avoid going idle in case of network problems. The server side must remember which WUs have been assigned and re-assign them after a certain timeout period, as the user may have quit the project and they will never complete.

2) There should be a stats page to make it more interesting. Who is the lead cruncher, cruncher of the day and all that, like SETI.

3) You should have a super fast client for this, something coded just for perft. In fact you should probably have 2 independent clients and randomly validate the result not just between programs but also between users, so that every user is checked for credibility. Some users may have faulty hardware or overclock to the extent that it occationally flips a bit, such clients must be detected and denied access.

4) Some kind of security, so that a single user cannot intentionally send you garbage data and sabotage the final result. I image something like a username/password and an computed checksum on each message.

But it kinda seems like a lot of work, just for perft..

[sje]

EDIT: rectification: your preft is up to nearly 8 times faster than mine! Impressive!

I hadn't looked at CookieCat in so long that I'd forgotten that it had a multithreaded perft.

[sje]

But it kinda seems like a lot of work, just for perft..

It is a lot of work, and especially so because of the possibility of maleficent users. I did a lot of SETI@Home in the old days more than a decade ago before it became part of BOINC, and it had many growing pains in spite of having a bevy of grad students doing coding work.

[Don]

Maybe I shouldn't say too much about perft(14), because I once said that I wasn't interested in doing perft(13) and look at what happened.

It is possible that perft(14) has already been calculated; any of a number of government parallel supercomputers could grind out the result in an afternoon or less. And it would be a good test of distributed integer performance, but it would not be made public.

With consumer level hardware, a distributed approach to perft(14) seems best at this time. But it is a non-trivial task. Consider any number of well known distributed computing projects where the end-user application has had dozens of revisions to squeeze out bugs. Perft(n) cannot admit a single off-by-one error; any bug would mean a restart.

For perft(14), I'd consider generating the 96,400,068 ply seven positions (each with a usage count) and deal these to worker clients with each position getting a draft 7 calculation. Averaging three per second would allow the run to complete in about one year, but without any redundancy checking. Tripling the time (or the processors) would support 2-from-3 majority voting for flagging bad intermediate results.

Steven,

You need to produce a binary and ask people to run them blind while sending you the output which the binary will place in a file. For each "work assignment" send out 2 for verification. Collect the results on your end. Make the assignments bite size, something that can be run in an hour or so and encourage people to run as many as they want. You could set up a simple server to make the assignments and report the results and they could even be random (you want duplication for verification.)

Just a suggestion.

Don

[sje]

On the other hand, the Adapteva gang at http://www.adapteva.com/ are promising an 8x8=64 core chip for US$200; they also talk of a future 32x32=1,024 core chip in the near future. Each core is a 32 bit RISC with a chunk of shared RAM, runs in MIMD mode, and is supposedly optimized for floating point operations. If the RAM is big enough and the instruction set has decent bitboard support, then a machine using a number of Adapteva chips could handle perft(14) fairly well.