Author: Robert Hyatt
Date: 19:01:35 05/01/00
Go up one level in this thread
On May 01, 2000 at 20:09:06, Peter McKenzie wrote: >On May 01, 2000 at 18:50:24, Robert Hyatt wrote: > >>On April 30, 2000 at 22:34:17, Christophe Theron wrote: >> >>>On April 30, 2000 at 18:42:57, Amir Ban wrote: >>> >>>>On April 30, 2000 at 16:39:04, Christophe Theron wrote: >>>> >>>>>On April 30, 2000 at 06:47:29, Amir Ban wrote: >>>>> >>>>>>On April 29, 2000 at 11:31:09, Eran wrote: >>>>>> >>>>>>> >>>>>>>I am sorry if I said it. Okay I believe you that Junior6 has underpromotion code >>>>>>>and that's wonderful. Maybe I will consider buying it. Does Junior6 consume >>>>>>>hashtable memory as large as fritz does? Is having large hashtable memory >>>>>>>important for Junior6? Is 40 MB hashtable enough for 40/120 games? >>>>>>> >>>>>>>Eran >>>>>> >>>>>>More memory for hash is good, but Junior is not very sensitive to it and you can >>>>>>change memory size by order of magnitude without obvious effect on playing >>>>>>strength. >>>>>> >>>>>>The comparison to Fritz is interesting and backward: I believe that Fritz 6 >>>>>>(new) consumes less memory than previous versions and the reason may be a >>>>>>conversation I had with Frans about this in Paderborn, from which he may have >>>>>>decided that he doesn't need so much memory. >>>>>> >>>>>>Amir >>>>> >>>>> >>>>> >>>>>I must admit I don't understand what you say... >>>>> >>>>> >>>>> Christophe >>>> >>>> >>>>Then why don't you ask :) >>>> >>>>I understood from Frans that he's hashing quiescence nodes. I told him I don't, >>>>and that I consider it a waste of time. >>>> >>>>Amir >>> >>> >>> >>>I hash quies nodes. I tried both methods (hashing them and not hashing them) and >>>found that hashing QSearch nodes was definitely better, but not by much. I did >>>hours of experiments and drew a lot of curves with my spreadsheet in order to >>>find this. >>> >>>It works better even if the hash table is highly saturated. >>> >>>That's how it works for me. I don't think that I have a better hashing/replacing >>>strategy, actually it is rather simplistic. Maybe it's because I do more in >>>QSearch than both of you do, although I cannot know for sure. >>> >>>Maybe I should check again... :) >>> >>> >>> >>> Christophe >> >> >>I used to hash q-search nodes. I found it reduced the size of the tree by about >>10%. I also found that by taking it out, I reduced the total search time by >>15 %. A net gain of 5%. More importantly, I don't need nearly the hash memory >>now since over half of the search is not hashed. > >I can't remember for certain, but I think I do hash the q-search. Like >Christophe/Tiger (but unlike Crafty), I do a bit more that just the minimal >q-search, so perhaps this is what makes hashing those nodes worthwhile for our >programs. > >> >>My next task is to save some time by getting rid of the hashing/unhashing code >>in the q-search as well, since it isn't used... > >I assume you are talking about updating the hash key? Surely this is a tiny >overhead, but it all adds up I guess. I wonder if the speedup (if any) will >offset the added complexity in your make/unmake functions, or do you plan to >create new versions of make/unmake? > >Sounds like you don't probe the hash table in q-search either? I think I do, >but don't have my source code handy to check. > > >cheers, >Peter Right, no probing in q-search. Whether the tiny speed boost is worth it or not, I don't know. I'll certainly find out before long... I will probably do separate make/unmake functions to avoid extra branches...
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.