hgm wrote:In my experience deep perft are very useful for testing move generators. An advanced move generator can have unexpected bugs that manifest themselves only in very rare situations. (E.g. capturing piece along the pin line when you use special code for pinned pieces, or a typo in a list of moves in a per-square target table.) You would only notice it in the perft of very special positions, that take many moves to set up from any plausible initial positition. (E.g. imagine a bug in the move table for a white King on e8...)
Doing sufficienty deep perfts would be very costly if you did not have an efficient perft program, so speed is a real issue there. Especially as during debugging you need to run the perft several times to zoom in on the error. Perft errors often have the nasty habit of disappearing when you start the perft from a position later along the branch with the error. (At least, they had for me in Joker.)
I can only second all of what is written above. And sometimes even a good bug hunting strategy including running perft tests with lot of different positions doesn't uncover all of the bugs unfortunately.
Last week I spotted an overlooked bug in my ep-move generation only due a loss on time in a game (Thanks to Olivie Deville again for telling me). This bug had the nasty habit of only showing up in very rare situations and therefore wasn't found when I ran my test-suite to check the validity of the generated moves.
hgm wrote:In my experience deep perft are very useful for testing move generators. An advanced move generator can have unexpected bugs that manifest themselves only in very rare situations. (E.g. capturing piece along the pin line when you use special code for pinned pieces, or a typo in a list of moves in a per-square target table.) You would only notice it in the perft of very special positions, that take many moves to set up from any plausible initial positition. (E.g. imagine a bug in the move table for a white King on e8...)
Doing sufficienty deep perfts would be very costly if you did not have an efficient perft program, so speed is a real issue there. Especially as during debugging you need to run the perft several times to zoom in on the error. Perft errors often have the nasty habit of disappearing when you start the perft from a position later along the branch with the error. (At least, they had for me in Joker.)
Of course total unoptimized i'm getting already millions of nps at perft with diep's generator which probably still is the fastest move generator around. For sure it is the fastest generic one around.
Do i read it correctly that you're defending optimizing just for perft?
p.s. as you know diep's move generator has been put in GPL so everyone is free to use it, drop me a line to get it + support.
Optimizing what? If the purpose is to get a fast perft, then optimizing on perft seems the prudent thing to do...
How fast is Diep's move generator for perft? E.g. how long does a (non-hashed) perft(7) from the opening position take, and is this with or without actually making and unmaking the last ply?
hgm wrote:Optimizing what? If the purpose is to get a fast perft, then optimizing on perft seems the prudent thing to do...
How fast is Diep's move generator for perft? E.g. how long does a (non-hashed) perft(7) from the opening position take, and is this with or without actually making and unmaking the last ply?
How could i care for perft, i'm not getting paid for nonsense unlike you.
I did care for semi-legal move generation though and optimized for that.
Perft counts can also be used to test other parts of a chess program.
I have a compile flag which lets the full-fledged search generate perft numbers, so
that e.g. forgetting to filter killer moves from the remaining moves will be
detected.
