Yes of course I have a bug ☺bob wrote:Pawn hash should change absolutely nothing but speed. If that's not true, you definitely have a bug. Node count should remain identical, as should the score, PV and everything else. You should see an improvement in speed proportional to the time spent in pawn evaluation. If pawn evaluation takes 10% of the execution time when you do a profile run, the pawn hash version should run 10% faster since the pawn eval will hardly ever be executed...Daniel Anulliero wrote:Thanks to HGM, daniel josé and Bob for your answers !
Well I've implemented the pawn hash today and made some tests , the two versions , with and without pawn hash (too few tests for the moment , it take some time
)
In the first test I had 330 ms of speed gain
5 moves , one depth more
In the second only 65ms
12 moves , one depth more.
In the first test, 3 times (out of 41 moves), two diferents moves (collisions or search instability?)
In the second test , 6 times (out of 71 moves) two diférents moves (collisions or search instability?)
To be continued ...
A simple debug test is to look up the pawn eval in hash, save it, then compute the REAL eval anyway and compare the two results. If they are not the same, fix the bug.
I was too lazy to implement the hascode pawns and the update in make / unmake
So , I took my two bitboard signatures I use for the eval (for black and white pawns) xored together...
Ooh big mistake , silly error lol
When they are xored we can't know where are white pawns and blacks pawns ...
I 'll do the stuff now in the right way
Anyway , thanks bob !
Bests
Dany