It amazes me that IID has such a big impact, this is probably because you have no other means of sorting yet.BertTuyt wrote: I have implemented (as is) the 8P DB-driver from Ed, and did some experiments with the Woldouby position.
First of all its close to a miracle to see a zero after many plies.
I also tested if different decrement depth methods would yield a difference in number of nodes, before the program finds a draw.
In below table I tested 3 methods.
1) Decrement depth always, 2) Decrement if number of moves > 1, 3) Decrement in case no capture move.
Next to that I included and excluded Internal Iterative Deepening in the case no hashMove was available.
Further no sorting, or killer, or History.In addition I added in the evaluation function if ( iXWhiteKing > 0 && iXBlackKing > 0) ) iEvaluation /= 2;Code: Select all
Method IID Nodes Ply 1) Always Off 253.347.095 30 1) Always On 206.719.204 30 2) Moves > 1 Off 210.825.319 22 2) Moves > 1 On 139.853.005 22 3) No Capture Off 248.610.432 20 3) No Capture On 138.422.730 20
So far I only included DB-scan in the PVSearch and not the QSearch, which I also need to do, and then run tests again.
With Ed's EGDB added I see the Woldouby draw at depth 28 (probing in quiescence), maybe I see the draw 2 ply earlier because I do promotions in quiescence.
Unfortunately I can't repeat your experiment atm., although Ed's EGDB is very fast it slows down my search by a factor 4 on positions like the Woldouby when I probe it in quiescence so I temporary removed it. Maybe I need a faster SSD on the PCI-e bus or larger memory for cashing, I still have to play with it a little.
Joost