Post mortem: There is a significant improvement, and this change is a step in the right direction! However, there is still some work/investigation to do.
My GnuBG uses an evaluation setting of “Supremo for Checker” and “World Class for Checker” with all the default options for that configuration. When I do 4 ply analysis from the GUI I up the plies from 2 to 4 for both cube and checkers. I mention this in the event that people wish to reproduce this.
With that being said I generally use the command line version of Gnubg on Linux (with –t option) and run test scripts. I’m using Linux on an Intel Dual QuadCore (Debian Lenny Stable). For these tests I used full –O3 optimizations and enabled SSE2 and enabled threads. Code was a CVS checkout after Jon committed the changes.
Previously we would get output as described here when a large cache was used:
The data we get now is below. Clearly there is a big improvement when cache=4194304 (Whether pruned or not) over the results at the link above. The values seem as if they aren’t just regurgitated 0ply masquerading as 4ply (At least not in the obvious scenarios). Although the results look good, thing get a bit uglier when you look at the cache=0 entries. Everything being equal (The results can be reproduced, the output seems deterministic) - Cached evals <> No Caching Evals.
I haven’t provided the output, but I ran 0,1,2,3 plies (Same filter and other settings). In those instances Cache Evals = No Cached evals, which leads me to believe we still have an issue with plies >3 with caching that hasn’t been discovered. I will look at the code more tonight and if I see anything I’ll let people know. My guess is we have missed something small somewhere (I hope).