Introducing Omniperft

[ilari]

Link: http://repo.or.cz/w/omniperft.git
You can download the source code by clicking the "snapshot" link next to the latest commit.

I'm developing a cross-platform chess gui for 8x8 and 10x8 variants with a friend. We of course needed an easy-to-use, flexible internal chessboard module or class to support all the variants, and a good debugging tool for it. I couldn't find a perft utility which could handle FRC, Capablanca chess, Capablanca Random chess, or Gothic chess positions, so I wrote one myself, called Omniperft.

I'm still a bit new to C++, so this was a good opportunity to try to forget about my C habits and do things the C++ way. And if you're wondering why the header files are packed so full of documentation, it's because we're using Doxygen to generate automatic API docs.

It's pretty simple to use, and has only the following commands (no command line arguments):

Code: Select all

moves                Print a list of legal moves
perft [d]            Print a perft value to depth [d]
divide [d]           Perft to [d] with a separate count for each move
printboard           Print an ASCII board and the FEN/X-FEN string
quit                 Exit the program
undo                 Reverse the last move
setboard [fen]       Set the board according to a FEN/X-FEN string
[move]               Make [move] on the board. Accepts SAN and Coordinate notation

So to get perft(5) for eg. the Gothic chess starting position, just enter:

Code: Select all

setboard rnbqckabnr/pppppppppp/10/10/10/10/PPPPPPPPPP/RNBQCKABNR w KQkq -
perft 5

There are a couple of favors I ask:
- Could someone test Omniperft with more Capablanca/Gothic positions? I only found a couple of reference figures on R. Scharnagl's site.
- Can I get a decent Windows build of this? I don't know why, but my MSVC builds are sluggish.

Here's what I mean by sluggish:
Perft(7) of initial chess position:
- Linux 64-bit (compiled with GCC): 105 seconds
- Windows 32-bit (compiled with MinGW): 186 seconds
- Windows 32-bit (compiled with MSVC): 257 seconds

The board representation doesn't use bitboards, so the speed gap between 32-bit and 64-bit shouldn't be that huge.

[smrf]

Interesting to hear from that project. It might be helpful to discuss how algebraic and explicite move representations should look like, especially regarding castling moves with traditional, symmetric, modern or free castling. I have made an early attempt introducing X-FEN, but slowed it down because of very divergent points of view. Maybe some kind of convergence would make sense now. I have very detailed compatible suggestions to that now.

If you want to have some more perft results, please suggest some positions, I would calculate on those for comparing purposes then.

Reinhard.

[ilari]

Interesting to hear from that project. It might be helpful to discuss how algebraic and explicite move representations should look like, especially regarding castling moves with traditional, symmetric, modern or free castling.

I used SAN without any modification, and Coordinate notation as specified in the Xboard protocol (with SAN-style castling).

I have made an early attempt introducing X-FEN, but slowed it down because of very divergent points of view. Maybe some kind of convergence would make sense now. I have very detailed compatible suggestions to that now.

If a program understands X-FEN, it understands also FEN and Shredder FEN, so to me X-FEN was a good choice. In our GUI users will be able to choose between X-FEN and Shredder FEN for PGN output.

If you want to have some more perft results, please suggest some positions, I would calculate on those for comparing purposes then.

Reinhard.

Any positions which test the castling rights code and/or promotions are fine.

[Denis P. Mendoza]

Ilari, could you test how fast this simple ICC compile is?

http://computerchessengines.mylivepage. ... ileid=3994

Thanks

Denis

[Denis P. Mendoza]

Ooops! Sorry, I just recompiled your latest snapshot. The first one was your first released snapshot:

http://computerchessengines.mylivepage. ... ileid=3995

[smrf]

Any positions which test the castling rights code and/or promotions are fine.

http://www.chessbox.de/Compu/schachzahl7_e.html could be fine ...

[pedrox]

AMD64 X2 4600+ (2 threads) + windows xp 32 bits

- ICC compile of Denis.

Perft 7 --> 278 s

- MSVC 2005 (no pgo)

Perft 7 --> 310 s

- MSVC 2008 (pgo)

Perft 7 --> 288 s

Denis, your compilation is PGO?

Pedro

[ilari]

Ilari, could you test how fast this simple ICC compile is?

Perft(7) took 217 sec, so it looks like my MinGW build is still fastest. This is weird, usually MinGW produces the slowest executables. Maybe I have some inefficient part in the program that GCC optimizes, but MSVC and ICC don't - like the famous example of using strlen() in a tight for loop. Or maybe the compiler options just weren't quite right. A profiler would probably help, but I don't know of any decent free ones that support MSVC.

Here's the MinGW build: http://koti.mbnet.fi/~ilaripih/bin/omniperft-win32.zip

[ilari]

Any positions which test the castling rights code and/or promotions are fine.

http://www.chessbox.de/Compu/schachzahl7_e.html could be fine ...

Thanks, for some reason I didn't notice that one. I tested up to depth 6, and the numbers matched.

[Dann Corbit]

No PGO optimization:

Code: Select all

OmniPerft 1.0 by Ilari Pihlajisto

r n b q k b n r
p p p p p p p p
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
P P P P P P P P
R N B Q K B N R
FEN: rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1
perft 3
Perft with 4 thread(s)
8902
Elapsed time: 0 second(s)
perft 4
Perft with 4 thread(s)
197281
Elapsed time: 0 second(s)
perft 5
Perft with 4 thread(s)
4865609
Elapsed time: 1 second(s)
perft 6
Perft with 4 thread(s)
119060324
Elapsed time: 8 second(s)
perft 7
Perft with 4 thread(s)
3195901860
Elapsed time: 111 second(s)
[code]