Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: hash entry replacement schemes (more)

Author: José Carlos

Date: 04:48:11 09/15/02

Go up one level in this thread


On September 15, 2002 at 07:44:18, Dave Gomboc wrote:

>On September 15, 2002 at 04:27:44, martin fierz wrote:
>
>>i wish i knew :-)
>>i've forgotten what exactly i did in my 2-table code. i think i kept my
>>"important table" relatively empty, and probed "forever" until i found a place
>>to store the entry. "forever" was usually once, but on occasion more.
>>i never quite figured out why this turned out to be less efficient than a single
>>table. it's well possible that my implementation was bad... the other thing i
>>thought about was that in checkers, you often have a situation where you can
>>reach the same position with variable depth - happens in any endgame with kings.
>>now, i was relying on the depth from root to select the table i was probing in.
>>if a position stored in the "important" table turned up deeper in the search, it
>>might not have been found because it was looked up in the wrong table. the whole
>>thing with two tables seemed more complicated than with one, so i threw it out -
>>besides, the difference is probably really small, even with a better
>>implementation.
>>
>>aloha
>>  martin
>
>It seems to me that other things being equal (e.g. you use them in the same
>way), one table with two slots is going to be slightly more efficient -- or at
>least certainly not less efficient -- than two tables with one slot, due to
>better prefetching and caching behaviour.
>
>Dave

  Except for the fact that you're forced to two equal size tables, whereas with
two separate tables you can choose a bigger one for always replace, which seems
to work better as a.r. is mainly useful near the leaves.

  José C.



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.