Author: Tony Werten
Date: 23:52:33 05/01/00
Go up one level in this thread
On May 01, 2000 at 20:39:13, Christophe Theron 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%. > > > >Yes, that's approximately what I measured. > > > > >> I also found that by taking it out, I reduced the total search time by >>15 %. A net gain of 5%. > > > >That's where I differ. Taking hash probe/updating out of QSearch results in a >very marginal speed gain (in NPS) for me. > > > > >> More importantly, I don't need nearly the hash memory >>now since over half of the search is not hashed. > > > >I think there is no saving in memory. In QSearch, if the hash table slot is >available, I use it and will maybe gain something, and if it's not available >(because a more important information is stored) I end up not using the hash >info in QSearch, as you do. > >Not hashing in QSearch means you are not taking advantage of all the memory you >have to help you to decrease the size of your tree. It does not mean that you >will need less memory. > >You do not take advantage of a resource you have, as your result of a 10% >smaller tree when using HT in QSearch shows. > >Of course, the increased NPS in your case justifies your choice. > > > > >>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... > > >Yes, I thought of this possible speed gain. But then you have to write a special >version of make/unmake that you will use exclusively in QSearch, and design >another system to check for repetitions for example (as I assume that you use >the hash key to detect repetitions). How many quit moves do you allow in QSearch ? Do you allow all checkgiving moves as well ( even if they are not captures )? Allowing all checkgiving moves, then all checkevasive moves... isn't that the fastest way to blowup your QSearch ? > >This is maybe worth the effort for you, because you just generate captures in >QSearch (that means no repetition can happen in QSearch). But my QSearch does >more than that, so for me it's a real problem. My QSearch catches a lot of draws >by repetition. I guess that's where the difference is. Since you trie a lot more moves in Qsearch, it would be logical you have more to gain from hashing. There is a middleway. Just store say the first 4 plies in QSearch and always trie to retrieve. For my program this seems to work the most efficient. (If I could just get the rest of the program efficient) Didn't think about using a different make_move after those 4 plies, should give a speedup. Tony > >You also need to keep the hashing of pawn structures anyway, so all hashing will >not be taken out of the QSearch make/unmake. > > >But I understand that not hashing in QSearch can be a good decision for some >programs. > > > > Christophe
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.