Author: Stuart Cracraft
Date: 06:49:02 07/20/04
Go up one level in this thread
On July 20, 2004 at 03:10:36, Daniel Clausen wrote: >On July 19, 2004 at 23:02:40, Robert Hyatt wrote: > >[snip] > >>Too much trouble. When you finish an iteration, simply make sure that _all_ PV >>positions are in the transposition table along with the best move from the >>actual PV. Since you should always try the transposition table move first, >>this guarantees you that you will search the PV moves first with no extra >>code or overhead of any kind in the search. > >I guess that's the best solution overall which I will use in my new engine too. >The not so elegant part is that 'searching the PV first' and hashtables are >coupled - if you turn off HTs you no longer search the PV first. I guess as soon >as you have a reliable HT-implementation, this is a minor point though. > >Sargon This is what I had before the PV: search the hash move first. However, the PV itself was in the hash table and so the hash move being seached first would always follow the PV first. However, when I added the explicit code to compare the PV that was walked from the hash table after the last iteration, I picked up some performance and test results. This leads me to believe some of the PV was being damaged during the current iteration -- hence I store it separately. There is not a lot of code and it is a good insurance policy. I need to devote more time to move-ordering and have a small array of moves to try first (pv, hash, killer, etc.) prior to the move gen. This is high on my list of things to do. Stuart
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.