Author: Ed Schröder
Date: 23:08:14 01/26/00
Go up one level in this thread
On January 26, 2000 at 18:31:21, leonid wrote: >On January 26, 2000 at 13:24:21, Ed Schröder wrote: > >>>Posted by Peter W. Gillgasch on January 26, 2000 at 09:18:55: >>> >>>In Reply to: Re: DB NPS (anyone know the position used)? posted by Ed >>>Schröder on January 26, 2000 at 03:07:42: >>> >>>On January 26, 2000 at 03:07:42, Ed Schröder wrote: >>> >>>>On January 25, 2000 at 23:57:33, Ernst A. Heinz wrote: >>>> >>>>>> In a one by one setting it does not matter at all. >>>>> >>>>>Still not convinced: a quiescence node that produces a direct >>>>>"stand pat" cutoff obviously generates less work than one >>>>>which fails to do so -- even in hardware! *** QED *** >>>>> >>>>>Or am I missing something? >>>>> >>>>>=Ernst= >>>> >>>>Something else... I always wondered about this free 4-ply evaluation. I >>>>can understand that evaluation for the current position done in hardware >>>>is possible in a few cycles. I can't understand this also to be true for >>>>4 plies as it should involve: search, hash table, q-search etc. In other >>>>words a complete chess program. >>> >>>Well of course they have a complete chess program for interior nodes >>>in hardware as you know. The idea why I think that the position does >>>probably not matter too much is because something like 0.07 percent >>>of the nodes they do are calculated on the SP and the remaining >>>99.93 percent of the nodes are done on the hardware where the transition >>>from father to sibling and back has a fixed cost regardless of move >>>ordering. I am not saying that the size of the tree is not influenced >>>by the position, I am also not saying that the time it takes to complete >>>a 4 ply search on the chips does not depend on the position. >>> >>>You have experience with one by one move generators since your ARM >>>program did that. What is your gut feeling, assuming that all moves >>>spend the same time in MakeMove/UnmakeMove (hypothetical) and all >>>your move generators need the same time to produce the next move >>>(only a little hypothetical) and you have no instruction count >>>differences between the usual case versus the "get out of check" case, >>>would you see any major NPS differences between different positions ? >> >>I think you mixed me up with somebody else. I always do and have done >>a full move generation and then sort the move list first based on a fast >>static evaluation. I have tried the one by one approach but it was not >>superior. > >I am curious to see if I understood correctly what you have said. You find for >each ply all the moves and aline them in the way that the most promissing goes >first. What I would like to know is if all the moves that you generate for the >ply are legal. Yes. Ed >In my logic I use almost everywhere legal moves and I find all the moves for the >each ply before using them. Found that very few do the same. Now I see that >probably you do the same. This is why I make this question. >Leonid. > > > >> >>I suspect the reason is Rebel's expensive evaluation function. If you have >>a fast eval NPS will drop considerable doing a full move generation plus a >>quick-sort. Having a slow eval like Rebel you hardly see the NPS drop and >>you can afford such time consuming things. >> >>Ed >> >>>For me it is pretty much constant, ups and downs by maybe 1/6 which >>>I attribute to the varying execution times of MakeMove/UnmakeMove and >>>the differences between "in check" and "not in check" nodes. >>> >>>-- Peter
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.