Author: Daniel Clausen
Date: 09:24:40 06/18/02
Go up one level in this thread
On June 18, 2002 at 11:41:51, Richard Pijl wrote: [snip] >It is not only passing the list, also building and maintaining it. >When I changed my pv array to retrieving from the hashtable, it saved >me about 5%. 5% seems incredibly high for just updating the PV array. I didn't measure it in my engine (esp since I don't have HTs atm :) but still it seems way too much.. I spend about 5% of the total time in makeMove() and this function surely is -called more often than updating the PV moves -takes longer to execute So, in short, I'm puzzled by your 5%. :) Note: I could imagine to lose a bit when the arrays for the potential PVs are created on the stack but someone who uses the 'triangle array approach' shouldn't lose that much. On the other hand, I could be completely wrong. :) Do other people have numbers to compare? >I also simplified my moveordering (as I first checked for a PV move before >probing the hashtable), but that could have been done anyway. Yes, that will be much easier. I think I will also do that as soon as I have re-implemented HTs. >I keep the rootnode move in a separate variable, to prevent it from being >overwritten in the hashtable. Aha! A special case! :) I'm not sure but don't some people store the PV in the hashtable after a search, in case the PV nodes were overwritten in the meanwhile? Of course you'd have to keep the PV moves separately when doing this... >On the other hand I have a full PV-line on a 1 ply search depth when reusing >hash entries from a previous search, also on unexpected moves by the opponent That's a nice feature. :) Sargon
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.