Author: Scott Gasch
Date: 12:25:13 02/16/05
Go up one level in this thread
On February 16, 2005 at 00:33:25, Eric Oldre wrote: > >On February 15, 2005 at 15:52:31, Scott Gasch wrote: >> >>There are two kinds of speedups: lossy and lossless. Lossy ones are shortcuts >>like lazy eval... where you are searching a different tree after the change. >>These are great for speed but can kill you for strength so separate the issues >>of "nodes per second" from "my program is strong" in your brain. Just a few >>weeks ago I tested a change where I added an eval hash to my engine... the >>thought was, I call Eval() in the middle of the tree quite frequently (for >>"razoring" and other ideas)... so quite often I am re-evaluating the same >>position I just evaluated not too long ago. I thought it would be a big win to >>keep a small table of the last position sigs, their a..b window, their eval, and >>some other data my eval returns. Well I did this and it was great... 15knps >>faster. But when I ran the new version against test suites it did not do as >>well... in fact markedly worse. > >Scott, >This was a GREAT post, thanks for taking the time to write it. I'll probably be >ordering "hackers delight" tomorrow. > >I thought of something when you described the eval hash you did that may or may >not help out. It seems that from a search perspective. the eval hash that you >did should have been what you described as "lossless". Meaning, if the eval hash >was working correctly, your search should have been making the exact same >decisions about when to prune/razor etc, only faster. So if implementing it >increased the speed but decreased the strength, the idea may have been sound, >but could have had bugs in the implementation. > >Take this with a grain of salt of course. Monsoon is much stronger than my own >engine. So you have much more to teach me than vice-versa. But the above makes >sense to me. > >Eric Well, here are the things about an eval hash... 1. I do lazy eval. So an eval hash can't just store the position signature and score, it has to store the a..b bounds that Eval was called with. Then when you hit the eval hash you need to make sure the current a..b bounds are wider (or equal to) the bounds on the position you hit. 2. I don't just return a score from eval. In addition I return stuff like the location of trapped pieces, each side's king safety, a list of enprise pieces etc... This information used in various ways... like a side can't stand pat if it has trapped pieces, I wont do some kinds of pruning if king safety looks bad, the move generator orders moves of enprise pieces first etc... The catch is that I didn't store all this information in the eval hash record. So this potentially lossless change became a lossy one. The reason I chose to do this is because it would take a lot of space/time to store this data in the eval hash. Maybe it's worth trying, I'll probably have a go at it when I have time. Take my words with a grain of salt though -- on a 1.2ghz machine monsoon searches ~200k nps. So it's no speed demon by any stretch of the imagination. Scott
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.