As the name implies, frcperft is a perft program for Fischer Random Chess.
Features:
- full legal move generation
- bulk counting in leaf nodes
- bitboards
- magic move generation by Pradu Kanan
Example output for the opening position (corei7@2600Mhz, with SSE4.2):
Hi Allard
I am probably wrong but isn't frc chess same as standard except for the
opening position. In which case I belive your old iperft should give the same result ?
Please excuse my shameless request below.
Could you add also a perft for spartan chess ? We really need chess engines for that and it would be good if you can make bright or spark play spartan. Rules here http://www.spartanchessonline.com/ . Piece movements are different for spartan pieces. Aside from the issue of two kings , the implementation is pretty easy.
Changes are minimal and you don't have to implement eval stuff. I am sure the wood counter bright would destroy all of us.
Thanks for the sources. I like optimized code even though I would never write it.
cheers
Daniel
Daniel Shawul wrote:Please excuse my shameless request below.
Could you add also a perft for spartan chess ?
Sjaak has a perfter for Spartan, if you want it. It's not particularly optimised for it though, doing more work than it needs to for terminal nodes. It uses the same method as PERFT_SLOW in the frcperft program (I wanted to know why the posted times were so much faster than those I get from Jazz, so I had a quick look; Sjaak uses the same code as Jazz).
We really need chess engines for that and it would be good if you can make bright or spark play spartan. Rules here http://www.spartanchessonline.com/ . Piece movements are different for spartan pieces. Aside from the issue of two kings , the implementation is pretty easy.
Yup. More entries for the next tournament would be fun!
Oh no Evert, that was my lazy attempt to get people interested in spartan. Actually perft is what I did first, to compare my result's with HG's. Fast perfts usually use bulk counting and hash tables. I don't like bulk counting because it doesn't reflect what actually happens in a real search.
Sorry Allard for hijacking your thread.
Daniel Shawul wrote:Hi Allard
I am probably wrong but isn't frc chess same as standard except for the
opening position. In which case I belive your old iperft should give the same result ?
Well, as King and Rooks can start from different positions than standard, your perft have to know how to castle. Maybe this can make some difference.
Daniel Shawul wrote:Hi Allard
I am probably wrong but isn't frc chess same as standard except for the
opening position. In which case I belive your old iperft should give the same result ?
Yes, FRC chess is a superset of standard chess and the perft counts of the opening position should be exactly the same.
However, in other positions, there are a couple of pitfalls to watch out for involving castling.
E.g. in the next position castling to the queen side is illegal, because the rook on b1 is pinned:
[D]3k4/8/8/8/8/8/8/rR2K3 w Q - 0 1
The reason I wrote frcperft is that I am adding FRC support in Spark's next release. As Spark started out as a bitboard perft, I thought I'd upgrade it to support FRC too and see how fast I could make it.
On 64 bit systems, frcperft is now faster than my older i-perft on which Bright was based.
Daniel Shawul wrote:
Could you add also a perft for spartan chess ? We really need chess engines for that and it would be good if you can make bright or spark play spartan. Rules here http://www.spartanchessonline.com/ . Piece movements are different for spartan pieces. Aside from the issue of two kings , the implementation is pretty easy.
Changes are minimal and you don't have to implement eval stuff. I am sure the wood counter bright would destroy all of us.
Thanks for the sources. I like optimized code even though I would never write it.
cheers
Daniel
Spartan chess sounds interesting, but I am afraid it is not a top priority for me.
Why aren't you inclined to writing optimized code, I should think the frcerft source code is still quite readable and malleable?