Author: Bas Hamstra
Date: 08:08:59 03/28/00
Go up one level in this thread
On March 28, 2000 at 10:37:09, Tom Kerrigan wrote: >On March 28, 2000 at 09:18:06, Gordon Rattray wrote: > >>On March 28, 2000 at 07:59:43, Tom Kerrigan wrote: >> >>>On March 27, 2000 at 12:26:02, Gordon Rattray wrote: >>> >>>>How much benefit can one expect by supplying more RAM for hash tables? I'd >>>>guess that moving from, say, 32Mb to 128Mb would be a significant improvement >>> >>>I'm not sure about this. At least with my program, having _A_ hash table is a >>>significant improvement, but the size doesn't matter that much. Anything over, >>>say, 1MB just changes things by a few percent here and there. >>> >>>-Tom >> >>What I don't understand is this... I'm sure I've read somewhere that the search >>efficiency of Fritz degenerates significantly once the hash table has been >>filled. This suggests to me that a bigger hash table would allow it to search >>more before the efficiency drops. Also the drop may be slightly less?! >> >>Also, as a simplified example, wouldn't a program perform better if it can keep >>a hash table entry for all positions within a 6 ply search as opposed to 5 ply? >>Surely, a further search to 7 ply would then be quicker for the former case (all >>6 ply entries)? >> >>Please note that my understanding of chess algorithms is limited and mainly >>involves alpha-beta. >> >>Gordon > >Yeah, this stuff is kind of confusing to me, too. But two comments. > >There are two possibilities regarding Fritz. First, the move ordering is not so >good. A bigger hash table means a bigger crutch for move ordering. Second >possibility: Fritz's hash entry replacement scheme is not so good. A bigger hash >table means a bigger chance that the important entries will stay in it longer. > >Second comment: the effectiveness of the hash table depends on the depth of your >search. If you add a hash table to a program that only searches 3 ply, its >effectiveness will be almost nil. If you make a mistake ordering moves during a >3 ply search, you might end up searching maybe 50 extra nodes or something. >Whereas if you make a mistake ordering moves during a 10 ply search, you might >end up searching a few extra million nodes. So the important thing is that the >hash table contains entries for the high-depth nodes. I guess that ~1MB of >high-depth entries will allow you to avoid the big move ordering mistakes. > >So my conclusion is that if you have a pretty good move ordering scheme and a >pretty good hash entry replacement scheme, you only need a small hash table. I >could be totally wrong about all of this, though. > >-Tom Question is: is move ordering very important near the root and less important near the leafs? Bob Hyatt says so. One mistake near the root costs millions of nodes. On the other hand almost all nodes are leafnodes, so bad ordering near the leafs costs millions of nodes too. Has anyone measured if you search somewhat deeper if you do extensive ordering near the root and cheap (just MVV/LVA) ordering near the leafs and in the qsearch? Sigh. Why has everyone to invent all the weels over and over. There are a lot of this type of facts that could be easily more or less scientifically established and written down. I suspect a lot of these matters are program independant. Yet... Regards, Bas Hamstra.
This page took 0.01 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.