Perft(14)

[sje]

I'm going to work on the ply N unique position generator as any distributed approach is likely to need one of these.

I have a program that can do just this -- I can modify it quite easily to output in FEN format.

So do I, except that it's written in Lisp. I'm doing the Pascal version as it can be ported to dozens of target hosts, as can the perft client code.

Actually, back in the Old Days I had a C version, but like most of my code written more than a couple of decades ago, it is (thankfully) long lost.

[Don]

I'm going to work on the ply N unique position generator as any distributed approach is likely to need one of these.

I have a program that can do just this -- I can modify it quite easily to output in FEN format.

So do I, except that it's written in Lisp. I'm doing the Pascal version as it can be ported to dozens of target hosts, as can the perft client code.

Actually, back in the Old Days I had a C version, but like most of my code written more than a couple of decades ago, it is (thankfully) long lost.

I already have a distributed perft system in place. I'm testing it now locally and ironing out any glitches. Any number of volunteers should be able to help simply by running instances of it. I'm hoping to test it on perft 10 before starting the official perft(14) run.

[Don]

I'm going to work on the ply N unique position generator as any distributed approach is likely to need one of these.

I have a program that can do just this -- I can modify it quite easily to output in FEN format.

So do I, except that it's written in Lisp. I'm doing the Pascal version as it can be ported to dozens of target hosts, as can the perft client code.

Actually, back in the Old Days I had a C version, but like most of my code written more than a couple of decades ago, it is (thankfully) long lost.

I already have a distributed perft system in place. I'm testing it now locally and ironing out any glitches. Any number of volunteers should be able to help simply by running instances of it. I'm hoping to test it on perft 10 before starting the official perft(14) run.

I set it up to do perft(9) (from the 9 million 6 ply starting positions) doing perft(3) searches running several local instances of the client on my quad. It was handling 60 posts per minute. I don't really know if it can handle a lot more or not - but at that rate it would still take 2 days so that is a low bound on how quickly we can calculate perft of ANY value based on starting from the unique 6 ply positions. It's likely it can handle a lot more than 60 client calculation per second but I don't have an easy way to test this.

I need a Linux server that is public to do this - can anyone loan one to me for a few months (with a login for it?)

Also I need some client binaries that follow the protocol I published. Are any of these ready? We could at least trying doing perft(10) as a dry run.

Don

[sje]

I suppose it's a good thing that there's some perft interest in the community nowadays, as it was pretty much dead from 2006 until 2011 when I did the perft(12) verification.

[Don]

I suppose it's a good thing that there's some perft interest in the community nowadays, as it was pretty much dead from 2006 until 2011 when I did the perft(12) verification.

Your Pascal program compiled for me without any trouble, but doesn't produce conforming output to be used in the GUI client. It's not really unix-like as it's more of an application, not a command line tool.

I will make a wrapper for it.

[ibid]

Also I need some client binaries that follow the protocol I published. Are any of these ready? We could at least trying doing perft(10) as a dry run.

Is the program REQUIRED to output each move as it is searched?
Do you have linux and windows clients already, or just linux?
And... is there the possibility of a non-graphical linux client? My linux is command prompt only... :)

Thanks, you've put a lot of things together quite quickly!
-paul

[Don]

I suppose it's a good thing that there's some perft interest in the community nowadays, as it was pretty much dead from 2006 until 2011 when I did the perft(12) verification.

Your program cannot be wrapped without a lot of trouble because it's not doing the correct kind of I/O, it is prompting for input and I cannot just pipe commands to it. It will work if I write a script that connects to both ends of the pipe and waits for the prompt, etc but this is getting too complicated. It would be easier for me to fix up your code. Your code is really an application, not a command line utility.

Here is an example bash script that tries to do the right thing, but it will exit BEFORE the calculation is written to stdout:

Code: Select all

#!/bin/bash

export s=`cat <<EOF
sfen $1 2 2
perftbulk $2
exit
EOF
`

echo "$s" | ./cookie | while read line ;
do 
  echo $line
done

[Don]

Also I need some client binaries that follow the protocol I published. Are any of these ready? We could at least trying doing perft(10) as a dry run.

Is the program REQUIRED to output each move as it is searched?
Do you have linux and windows clients already, or just linux?
And... is there the possibility of a non-graphical linux client? My linux is command prompt only...

Thanks, you've put a lot of things together quite quickly!
-paul

I could make a command line client fairly easily. The program expects to see each move output for display purposes, but it's not required. The GUI displayed the board and all the moves and reports the results of each move as things progresses. So if the perft binary does not report intermediate results, it will just affect the display, nothing else and certainly not the integrity of the calculations.

[Don]

The code seems to work without the exit - the stdout comes through eventually. So I could process the result and then issue a signal nohup - when I recognize that the calculation is done - but that is really ugly.

I suppose it's a good thing that there's some perft interest in the community nowadays, as it was pretty much dead from 2006 until 2011 when I did the perft(12) verification.

Your program cannot be wrapped without a lot of trouble because it's not doing the correct kind of I/O, it is prompting for input and I cannot just pipe commands to it. It will work if I write a script that connects to both ends of the pipe and waits for the prompt, etc but this is getting too complicated. It would be easier for me to fix up your code. Your code is really an application, not a command line utility.

Here is an example bash script that tries to do the right thing, but it will exit BEFORE the calculation is written to stdout:

Code: Select all

#!/bin/bash

export s=`cat <<EOF
sfen $1 2 2
perftbulk $2
exit
EOF
`

echo "$s" | ./cookie | while read line ;
do 
  echo $line
done

[ibid]

The program expects to see each move output for display purposes, but it's not required. The GUI displayed the board and all the moves and reports the results of each move as things progresses. So if the perft binary does not report intermediate results, it will just affect the display, nothing else and certainly not the integrity of the calculations.

OK, thanks. Since mine couldn't output that even if I wanted it to. :)
I am reducing my perft program to something more appropriate for this right now and this thought comes up: how about the possibility of the client passing a number of threads to the perft as an extra argument? this way they could enter that in the GUI, change it as needed, etc. (although clearly it would not take effect until the next position), without each program needing to get that from an initialization file. Just a thought.

-paul