Bug in my perft

[ericlangedijk]

My generator produces accurate results for the first en third position on this site: http://chessprogramming.wikispaces.com/Perft+Results

The second position is accurate as well but at Perft(5) it misses 129 captures.

r3k2r/p1ppqpb1/bn2pnp1/3PN3/1p2P3/2N2Q1p/PPPBBPPP/R3K2R w KQkq - 0 0

The site says:
Nodes = 193690690
Captures = 35043416
Ep = 73365
Castles = 4993637
Promotions: 8392

My result are:
Nodes = 193690561 (-129)
Captures = 35043287 (-129)
Ep = 73365
Castles = 4993637
Promotions = 8392
UsedTime = 21716 (21 seconds)
NPS = 9112000

What's the smartest way to discover the bug?
I would like to see the timings for Perft(5) in this position from some of you to (1) try to enhance my algorithms (2) decide to leave Delphi for chessprogramming if I do not succeed.
For Perft I tried the same algorithm as Crafty which did not give better results than my original algorithm.

Apart from the - maybe - not so well optimized 64 bits operations in Delphi (on a 32 bit system) I would like too know how to optimize in general. Maybe trying to make hits in the processor cache, thus avoiding RAM access? If so how? Maybe use pointers to 64 bits numbers instead of assigning them (where possible)?

[micron]

Depth 5 is when white can promote the pawn, some as plain promotions, some as promotions-with-capture. I once had a bug in promotion-with-capture, so you might look there.

My speed (on 2.66GHz Core i5) in 32-bit mode is similar to yours. You can see the worthwhile but not overwhelming advantage of 64-bits. My perft() is as close as possible to the working move generator as used by Search(), with no specialised perft-only tricks.

Code: Select all

64-bit
depth 4  nodes   4085603      289 ms    1.4E+7/s
depth 5  nodes 193690690    13501 ms    1.4E+7/s

32-bit
depth 4  nodes   4085603      421 ms    9.7E+6/s
depth 5  nodes 193690690    19813 ms    9.8E+6/s

[ericlangedijk]

Thanks! I found the bug found. A typo when black promoted to a queen.

[sje]

A FEN string can't have a zero for a move number.
[d]r3k2r/p1ppqpb1/bn2pnp1/3PN3/1p2P3/2N2Q1p/PPPBBPPP/R3K2R w KQkq - 0 1
Also, its perft(8):

Code: Select all

Bb5 305,642,680,663
Bc1 299,879,274,628
Bc4 331,999,730,288
Bd1 232,299,228,024
Bd3 323,148,326,669
Be3 367,090,135,640
Bf1 334,227,994,103
Bf4 320,459,928,018
Bg5 349,225,586,853
Bh6 309,132,031,261
Bxa6 241,387,211,019
Kd1 274,750,767,755
Kf1 248,309,615,874
Na4 386,563,996,492
Nb1 314,690,850,723
Nb5 335,285,961,781
Nc4 270,362,407,999
Nc6 338,226,587,566
Nd1 313,541,077,840
Nd3 256,502,027,044
Ng4 258,333,972,987
Nxd7 392,791,660,921
Nxf7 342,156,201,114
Nxg6 321,396,995,625
O-O 334,274,439,913
O-O-O 276,865,226,742
Qd3 318,831,262,788
Qe3 374,069,077,176
Qf4 355,165,150,488
Qf5 460,271,562,178
Qg3 401,204,979,014
Qg4 378,965,394,329
Qh5 393,307,640,844
Qxf6 264,835,246,136
Qxh3 426,819,204,139
Rb1 305,422,602,641
Rc1 302,507,795,871
Rd1 279,687,999,714
Rf1 289,675,094,245
Rg1 320,668,896,061
a3 402,654,556,153
a4 363,636,312,256
b3 287,466,826,392
d6 281,928,947,052
dxe6 416,725,713,915
g3 252,982,671,742
g4 238,841,590,165
gxh3 299,731,647,143

Count: 15,493,944,087,984

[sluijten]

What's the smartest way to discover the bug?

Write a function 'debugmove', call at it the end of (un)makemove and have it check board consistency - do all board variables tell the same?
If not then stop and display the board, with respective bitboard(s), all the moves that led to this position (especially the last one , etc.
(De)activate the code with a compiler directive.
That's how I do it.