Author: Robert Hyatt
Date: 13:48:22 01/16/03
Go up one level in this thread
On January 16, 2003 at 15:15:42, David Rasmussen wrote: >On January 16, 2003 at 14:49:54, Robert Hyatt wrote: > >>On January 16, 2003 at 14:35:25, David Rasmussen wrote: >> >>>On January 16, 2003 at 14:22:01, Dann Corbit wrote: >>> >>>>Do you probe in quiescent search? >>>> >>> >>>No >>> >>>>Under what conditions do you probe? >>> >>>I think my code is self explanatory (probably not...): >>> >>> /* >>> * Probe the endgame tablebases >>> */ >>> >>> if (ply <= iterationDepth >>> && EGTBEnabled >>> && PopCount(pos.occupied[WHITE] | pos.occupied[BLACK]) >>> <= EGTBLimit >>> && ( >>> Capture(currentMove[ply-1]) >>> || Promote(currentMove[ply-1]) >> >>wasted test. > >What exactly? > >> First, check for Capture(). Why do the PopCnt first when it is >>slow? > >You might be right, but it's not relevant here. It's not what is making the >heavy probing slow, I think. > >>Then check for popcnt or (better) just keep a count of pieces on the board and >>update >>it incrementally. Finally, dump the Promote test. If you have all egtbs you >>can never >>get here as you would have gotten a hit previously. >> > >Sure. I keep it for safety and generality, if I should someday decide to run >with partial 6-man tables for instance. Anyway, none of these comments addresses >my problem, I think. I don't think those are what is killing my speed. I will >check, though. > >/David See my response earlier. With 8-9 pieces on the board, you are doing a worst-case test, as many lines will turn into a probe. With more pieces, this tapers off. And, of course, if you are in a game, the cache gets "seeded" slowly so that the drop-off won't be as bad as when starting off in a near-EGTB position.
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.