Author: Robert Hyatt
Date: 15:25:09 09/22/04
Go up one level in this thread
On September 22, 2004 at 18:02:50, martin fierz wrote: >On September 22, 2004 at 13:07:22, Michael Henderson wrote: > >>On September 22, 2004 at 05:10:56, martin fierz wrote: >> >>>On September 21, 2004 at 17:36:47, Stuart Cracraft wrote: >>> >>>>Hi -- this past weekend I switched from single-tier replace >>>>always to two-tier place 1st tier in 2nd if incoming position >>>>is searched to a >= depth than currently stored at hash entry >>>>and store incoming position in 1st tier, otherwise always replace >>>>2nd tier if depth is. >>>[snip] >>> >>>i use only one hashtable in my program. whenever i tried using 2 tables, my >>>results were worse. i tried this many times, because everybody here says it's >>>better to use 2 tables. i never got it working, and decided to stick with 1 >>>table, as it is much simpler overall. >>> >>>IIRC dieter buerssner also mentioned that for him 1 table worked just as well as >>>2 tables. >>> >>>as others have said, if you want to benchmark this you'll have to use longer >>>searches - and to do that you should use a different test than WAC, i suggest >>>using ECMGCP, that is much tougher and more suited for longer searches. you >>>could also artificially create lots of replacements by making the hashtable(s) >>>really small - but i'm not sure that that will give you a relevant result... >>> >>>cheers >>> martin >> >>What replacement strategy do you use for the 1 table? >> >>Michael > >IIRC i have 4 entries per index, and i always replace the one with the lowest >depth; even if the new entry has a lower depth than any of the 4 existing >entries. IIRC because 4 is a #define in my program, i can change that to >anything i like. > >it's possible that my 2-table approach was flawed of course. i just never got it >working better than the simple approach above. KISS... > >cheers > martin Yours should be better. two-table uses basically 3 entries per probe chosen from a set of two of course. You have more to choose from, so you should be more efficient. But there is a cost in terms of memory and time to fetch it. The main point is to have some depth-preferred entries, while guaranteeing that you _always_ store an entry somewhere (ie you _never_ choose an old entry and avoid adding a new entry... choosing the best candidate to replace from a set of four is good...)
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.