Author: Dan Newman
Date: 23:38:39 05/01/00
Go up one level in this thread
On May 01, 2000 at 22:01:35, Robert Hyatt wrote: >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... I tried this a few weeks ago (special make/unmake for the q-search). I removed a bunch of stuff: hashcode updating, EP target, castling rights updating, and 50-move-rule count updating. When I tested it the node counts were different. It turned out I had to put the castling rights stuff back in because I used that in the eval. The result was that I got the same node counts, but the node rate was down 2%--no doubt the extra code didn't help with the cache... I don't have an awfull lot of branching in make/unmake though. I use a big switch statement with move type as an argument so that much of the code is just a straight through calculation. If you have a lot of if-tests, adding q-search versions of make/unmake might well be a win. -Dan.
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.