Author: Walter Faxon
Date: 16:31:27 04/06/05
In a recent thread (http://www.talkchess.com/forums/1/message.html?419679), the problem of on-line lookup of 6-man endgame tablebases was discussed. The consensus was that for computer play, you could (maybe) load blocks of related positions from near the root, not make individual requests for the value of specific positions, since even fast net access is a snail compared to a good hard disk. Either way, it takes a good block of time. To a much lesser degree, even looking up the hash value for the current position can lose if its cache line isn't already loaded. Main memory lookup can require hundreds of processor cycles on modern hardware. (Probably a reason why Hyper-Threading(R) technology works so well for computer chess. When one thread stalls the other might be able to continue.) In between is the standard situation where a particular position in the tree has multi-depth subsearches returning with widely varying scores and suggested moves. You've reached a "hard" position. Or maybe before you've done any searching on a position, you've somehow statically determined that it is "hard" (like it will require a disk lookup). Either way, what should you do? My question is: Is it ever reasonable to just say "I'm going to leave the evaluation of this position until later, if necessary." And continue the search. It is possible and in many cases likely that the remaining search will cut off at least some of the hard positions, and you will discover that you never really needed to evaluate these in the first place. Maybe the search tree could be marked so that when the "easy" search has been completed you can then return to try to understand the remaining hard positions, in an order of how they affect the remaining tree. Has anybody written code that addresses this? -- Walter
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.