OpenCL perft() Technical Issues

[sje]

BWTC is 1,001 Brilliant Ways to Checkmate. The file is here: https://dl.dropboxusercontent.com/u/316 ... N/BWTC.fen

[Ajedrecista]

Hello Steven:

I isolated depth 3 results from WAC in both Richard's post and your upload to Dropbox. I get 15796091 for both of you (I hope I did not go wrong anywhere), so it seems that Richard went wrong in the sum.

I also isolated depth 4 and depth 5 Richard's results, and I got 551178617 and 22363709083, respectively, which match with Peter's results and also yours. I was wrong in my other post because I remember that I isolated depth 5 results, did the sum in Excel and the result ended in 9083, so I messed up things for an unknown reason. Sorry. Anyway, it is good to know that results match. Richard went wrong with some sums but not with each perft result.

Glad to see that Peter and you also agree in this test suite of 1001 positions. I guess that you will not have problems with 6838 positions I told you.

Regards from Spain.

Ajedrecista.

[sje]

For BWTC, Oscar says:

Code: Select all

Record count: 1001   Depth: 0   Total: 1001
Record count: 1001   Depth: 1   Total: 42011
Record count: 1001   Depth: 2   Total: 1222819
Record count: 1001   Depth: 3   Total: 49850468
Record count: 1001   Depth: 4   Total: 1579319824
Record count: 1001   Depth: 5   Total: 64664453704

[sje]

Another FEN file

I have taken the position data from the file http://marcelk.net/rookie/nostalgia/v3/perft-random.epd and produced the FEN file https://dl.dropboxusercontent.com/u/316 ... el6751.fen with, you've guessed it, 6,751 unique FEN records. (There were 86 duplicate positions and one bogus position [gentest-679, bad en passant target] removed from the original data.)

Oscar is presently chomping on the file, running perft(n) (n: 0..5). I'll post the results as they become available.

[sje]

From Oscar:

Code: Select all

File: marcel6751.fen  records: 6751   depth: 0   total: 6751
File: marcel6751.fen  records: 6751   depth: 1   total: 176989
File: marcel6751.fen  records: 6751   depth: 2   total: 4653644
File: marcel6751.fen  records: 6751   depth: 3   total: 138830595
File: marcel6751.fen  records: 6751   depth: 4   total: 4116844032
File: marcel6751.fen  records: 6751   depth: 5   total: 131645230038

[sje]

Some progress:

Some of the code needed for work unit processing has made it into the operft.c source, replacing the kludge that was used for FEN file processing. The OpenCL work shaper eats multiple records at a time, and so for the best possible throughput, all of the records for a work unit should be ready for digestion before hitting the GPU. The program now loads the entire text of a work unit file into memory all at once and uses a dynamically allocated two-way linked list of dynamically allocated nodes and strings. For a typical 100,000 record work unit, this requires about 8 MB memory. Similar allocations are needed for storing OpenCL parameter blocks and output results.

In another thread, I've posted the first version of a user guide for operft. The user guide for operftocl (the OpenCL version of operft) will be essentially similar.

Oscar's perft() has totally dumped fixed length ply limits and fixed length total move allocation. The old limits of 32 ply and a 8,192 entry move stack are gone. Does this make much difference? It certainly will if/when Oscar moves to using unsigned integers longer than eight bytes for summation.

And just for laughs, I increased the number of primes in Oscar's PRNG from 16 to 32. This just may be useful if Oscar is called to support a quadrillion random game statistics experiment.

Another idea I have for Oscar is to add some high speed, parallel mate finder code to build a program which will eat a PGN file of GM games and point out all the forced mates which were missed and maybe all the forced losses which were not avoided.

[mvk]

Another FEN file

I have taken the position data from the file http://marcelk.net/rookie/nostalgia/v3/perft-random.epd and produced the FEN file https://dl.dropboxusercontent.com/u/316 ... el6751.fen with, you've guessed it, 6,751 unique FEN records. (There were 86 duplicate positions and one bogus position [gentest-679, bad en passant target] removed from the original data.)

Oscar is presently chomping on the file, running perft(n) (n: 0..5). I'll post the results as they become available.

The duplicate positions are on purpose. With this I got a sanity check that the program resets its internals correctly. (and it is only 1%)

The bogus e.p. square is required by the FEN standard, as the last move was e4. Compliant implementations must accept it.

"An en passant target square is given if and only if the last move was a pawn
advance of two squares. Therefore, an en passant target square field may have a square name even if there is no pawn of the opposing side that may
immediately execute the en passant capture."

The chess programming wiki says this about it:

"The en passant target square is specified after a double push of a pawn, no matter whether an en passant capture is really possible or not"

I hate this part of the standard as much as anyone else on the planet, but it is what it is. I know there was talk about relaxing this requirement, but it haven't seen such talk make it into documentation. My current program accepts this e.p. square for this position, but doesn't emit it, BTW. I prefer to be non-compliant here. In this case it shouldn't prevent anyone from performing a search.

(I do reject illegal pins, because my move generator depends on knowing that the double pawn push was legal).

[Rein Halbersma]

The chess programming wiki says this about it:

"The en passant target square is specified after a double push of a pawn, no matter whether an en passant capture is really possible or not"

I hate this part of the standard as much as anyone else on the planet, but it is what it is. I know there was talk about relaxing this requirement, but it haven't seen such talk make it into documentation. My current program accepts this e.p. square for this position, but doesn't emit it, BTW. I prefer to be non-compliant here. In this case it shouldn't prevent anyone from performing a search.

(I do reject illegal pins, because my move generator depends on knowing that the double pawn push was legal).

Having a history-independent move generator is quite reasonable, IMO. Why would engines have to burden themselves with trying to proof a position could not have legally arisen? For this ep example, it is easy perhaps, but the ultimate result of that line of reasoning would be to construct a proof game for every position, or reject it as illegal otherwise.

[mvk]

Having a history-independent move generator is quite reasonable, IMO. Why would engines have to burden themselves with trying to proof a position could not have legally arisen? For this ep example, it is easy perhaps, but the ultimate result of that line of reasoning would be to construct a proof game for every position, or reject it as illegal otherwise.

I restrict myself to proving that the preceding double pawn move was legal, because my generator depends on that assumption at some point. I don't remember the details without looking at the code, but it had something to do with illegal pins and legal move generation.

[sje]

About that en passant target square in a FEN string:

The original FEN specification is incorrect concerning the en passant target square.

The correct version is: The en passant target square which appears as the fourth field of a FEN record shall be "-" (nil) if no en passant capture is available. If an en passant capture is available, then the en passant target square will be the name of the destination square of an en passant capture. Note that for a non-nil en passant target square in a FEN string there will be at least one en passant capture in the position described by the FEN string; there may be two.

(en passant target square == "-") if and only if (no en passant move available)

(en passant target square != "-") if and only if (at least one en passant move available)

Simple, really. If a program is to generate a FEN record, then the program needs to know how to generate moves. There is no need for complex retro-analysis at all.

Yes, the twenty year old version of the documentation is out of date. But the above is the only change from the original, so if you've read the above then you're up-to-date.