Moderator: Ras
Code: Select all
Rookie> perft 5
5 4865609 (0.156 seconds)
Rookie> perft 6
6 119060324 (4.125 seconds)
Rookie> perft 7
7 3195901860 (105.479 seconds)It was numbers like these that made me give up on rotated bitmaps.ericlangedijk wrote:Thanks for the response.
There is still a lot of optimization to do.
I make pseudolegal moves and check after having made the move if we runned into a check. I work with Bitboards and incrementally update 4 occupationmasks (normal, rotated90, rotated45 and rotated315).
Is this the best way to handle that? Or is there a smarter way?
To my astonishment GenerateMoves() took much less time than I thought.
GenerateMoves - 7,94% of the time used
MakeMove - 19,94% of the time used
UnmakeMove - 16,68% of the time used
RunnedIntoCheck - 14,31% of the time used
Where the rest of the time is going I still have to figure out.
I use Perft (after it runs correct in a lot of testpositions) now to check the basic speed.
What else is any better? I use magic because of the single occupied_squares bitboard that makes it more flexible, but I saw no speed gain by getting rid of the rotated stuff at all. It is just now more efficient to ask "If I remove this pawn here, will a rook now attack square X?" Before I would have to update all 4 occupied_squares bitboards before I could answer that and it made the code messier. Move generation didn't change a bit, and is, in fact, slower with magic because of the operations being done. But then Make/Unmake gain some speed by doing less updates, which turned into a "break-even" thing with regard to speed...jwes wrote:It was numbers like these that made me give up on rotated bitmaps.ericlangedijk wrote:Thanks for the response.
There is still a lot of optimization to do.
I make pseudolegal moves and check after having made the move if we runned into a check. I work with Bitboards and incrementally update 4 occupationmasks (normal, rotated90, rotated45 and rotated315).
Is this the best way to handle that? Or is there a smarter way?
To my astonishment GenerateMoves() took much less time than I thought.
GenerateMoves - 7,94% of the time used
MakeMove - 19,94% of the time used
UnmakeMove - 16,68% of the time used
RunnedIntoCheck - 14,31% of the time used
Where the rest of the time is going I still have to figure out.
I use Perft (after it runs correct in a lot of testpositions) now to check the basic speed.
The perft in komodo does not hash but it's still a very useful optimization since it allows you do correctness tests faster, or deeper, or both.bob wrote:Correct. Here are a couple of examples from Crafty, starting position. Core-2 duo laptop (2.53ghz):Dann Corbit wrote:Some engines hash perft counting, so keep that in mind when you do comparisons.
model name : Intel(R) Core(TM)2 Duo CPU P9600 @ 2.53GHz
perft 5: total moves=4865609 time=0.22
perft 6: total moves=119060324 time=5.36
No hashing or other tricks inside Crafty... it was never intended to be a speed test, but was a "correctness test" instead...
Bob, do you a checklegal() into makemove() or into the search()?bob wrote:Correct. Here are a couple of examples from Crafty, starting position. Core-2 duo laptop (2.53ghz):Dann Corbit wrote:Some engines hash perft counting, so keep that in mind when you do comparisons.
model name : Intel(R) Core(TM)2 Duo CPU P9600 @ 2.53GHz
perft 5: total moves=4865609 time=0.22
perft 6: total moves=119060324 time=5.36
No hashing or other tricks inside Crafty... it was never intended to be a speed test, but was a "correctness test" instead...
dont understand this. do you mean you generate all opponent captures when is your turn? that sounds strange to me. what it is usual is you generate the moves of who is in turn and the check if there is any ilegal with a is_attaked(k_sq) function, or allow the search to capture the king and return mate as score.....ericlangedijk wrote:As far as I could see Bob (Crafty) generates captures first. Then if a king is taken there the result is discarded.