It seems the fix of the problem reported by Jesus never made it to my website.
I pushed a fixed version now that adapts the hash key on under-promotions, and does test for contact checks. If there are any, it fakes that the last move was with this piece.
I guess this might give invalid output for impossible positions with multiple contact checks: the move generator would only recognize one, and allow capture of that checker, even though that would not solve the other contact check(s).
Code: Select all
C:\cygwin\home\perft>a 7 H24 "rnbqkbnr/ppN5/3ppppp/8/B3P3/8/PPPP1PPP/R1BQK1NR b
KQkq - 0 6"
Hash-table size = ffffff, Starts at b4b040,section = 1fffff
- - - - - - - - - - - -
- - - - - - - - - - - -
- - r n b q k b n r - -
- - p p N . . . . . - -
- - . . . p p p p p - -
- - . . . . . . . . - -
- - B . . . P . . . - -
- - . . . . . . . . - -
- - P P P P . P P P - -
- - R . B Q K . N R - -
- - - - - - - - - - - -
- - - - - - - - - - - -
Quick Perft by H.G. Muller
Perft mode: Hash-table size = 256MB, bulk counting in horizon nodes
perft( 1)= 2 ( 0.000 sec)
perft( 2)= 70 ( 0.000 sec)
perft( 3)= 1454 ( 0.001 sec)
perft( 4)= 51654 ( 0.000 sec)
perft( 5)= 1171698 ( 0.019 sec)
perft( 6)= 42212557 ( 0.232 sec)
perft( 7)= 1029536265 ( 4.919 sec)
C:\cygwin\home\perft>a 7 "rnbqkbnr/ppN5/3ppppp/8/B3P3/8/PPPP1PPP/R1BQK1NR b KQkq
- 0 6"
- - - - - - - - - - - -
- - - - - - - - - - - -
- - r n b q k b n r - -
- - p p N . . . . . - -
- - . . . p p p p p - -
- - . . . . . . . . - -
- - B . . . P . . . - -
- - . . . . . . . . - -
- - P P P P . P P P - -
- - R . B Q K . N R - -
- - - - - - - - - - - -
- - - - - - - - - - - -
Quick Perft by H.G. Muller
Perft mode: No hashing, bulk counting in horizon nodes
perft( 1)= 2 ( 0.000 sec)
perft( 2)= 70 ( 0.000 sec)
perft( 3)= 1454 ( 0.000 sec)
perft( 4)= 51654 ( 0.001 sec)
perft( 5)= 1171698 ( 0.019 sec)
perft( 6)= 42212557 ( 0.437 sec)
perft( 7)= 1029536265 (15.455 sec)
Weird thing is that it got 30% slower, though, on perft(6) from the opening position. Which does not execute any of the new code (which is all in the UnMake for promotions, and there aren't any promotions in perft(6)).
I have seen that before, where deleting some lines of unreachable code gave such a slowdown. I guess the solution would be to use a better compiler; I am using a very old gcc version.