Author: Robert Hyatt
Date: 11:30:03 04/16/03
Go up one level in this thread
On April 16, 2003 at 12:43:26, Vincent Diepeveen wrote: >On April 16, 2003 at 12:16:23, Robert Hyatt wrote: > >>On April 16, 2003 at 07:49:59, Vincent Diepeveen wrote: >> >>>On April 16, 2003 at 03:39:36, Tony Werten wrote: >>> >>>>On April 16, 2003 at 00:07:21, Robert Hyatt wrote: >>>> >>>>>On April 15, 2003 at 04:54:11, Tony Werten wrote: >>>>> >>>>>>On April 14, 2003 at 17:43:12, Robert Hyatt wrote: >>>>>> >>>>>>>On April 14, 2003 at 17:15:41, Vincent Diepeveen wrote: >>>>>>> >>>>>>>>On April 13, 2003 at 22:39:39, Robert Hyatt wrote: >>>>>>>> >>>>>>>>>On April 13, 2003 at 11:49:28, Vincent Diepeveen wrote: >>>>>>>>> >>>>>>>>>>On April 13, 2003 at 11:27:53, Robert Hyatt wrote: >>>>>>>>>> >>>>>>>>>>I said initially. It drops back to 10 splits a second in DIEP after a while. >>>>>>>>>>Search depth matters. >>>>>>>>>> >>>>>>>>>>Let's compare 2 things. >>>>>>>>>> >>>>>>>>>> time=45.98 cpu=464% mat=0 n=37870294 fh=88% nps=823k >>>>>>>>>> ext-> chk=638414 cap=249442 pp=9588 1rep=32966 mate=223 >>>>>>>>>> predicted=0 nodes=37870294 evals=14565859 >>>>>>>>>> endgame tablebase-> probes done=0 successful=0 >>>>>>>>>> hashing-> trans/ref=28% pawn=93% used=28% >>>>>>>>>> SMP-> split=431 stop=57 data=6/64 cpu=3:33 elap=45.98 >>>>>>>>>> >>>>>>>>>>MT 2 crafty 18.10 which i have here. 431 splits at 45 seconds. I guess you must >>>>>>>>>>limit in crafty the number of splits a lot as splitting is expensive in crafty >>>>>>>>>>when compared to the costs of a single node. >>>>>>>>> >>>>>>>>>I'm not sure how expensive it is compared to a node. I'll run a test where >>>>>>>>>I do the split overhead at every node to compare, however... >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>I don't limit them at all. The only limit is the YBW algorithm. But I split >>>>>>>>>at the root also, which reduces them signficantly... >>>>>>>> >>>>>>>>I can split at the root nowadays, but i have turned it off for diep. it gives >>>>>>>>too poor speedup for me. The interesting thing which searching SMP can give is >>>>>>>>transpositions at a big depth which possibly are overwritten by a sequential >>>>>>>>search. i don't want to miss them. >>>>>>> >>>>>>>Maybe you don't split at the root correctly. I limit this with some intelligent >>>>>>>guesswork, so that if it appears that I might change my mind this iteration, >>>>>>>then >>>>>>>I don't split at the root until I have searched all moves that I think might >>>>>>>replace >>>>>>>the best move... >>>>>> >>>>>>Just trying to understand. Are you talking about the case where the best move in >>>>>>the root got a fail low ? >>>>> >>>>>No. I search the first move with all processors for obvious reasons. I search >>>>>the next "N" the same way, where "N" is set by trying to figure out how many >>>>>moves _might_ become a new best move (I discover this by looking at the node >>>>>counts for each move after an iteration ends. If any are close to (or bigger >>>>>than) the node count for the first move, then they deserve special parallel >>>>>searching one at a time, before I split at the root and search a root move >>>>>with only one processor (which will take longer). >>>> >>>>Hmm, I thought I finally understood this crap. Isn't splitting at the root the >>>>most desireable situation ? If you have (after bestmove) 2 moves that deserve >>>>special attention, why not search them parallel. Most of the time they will not >>>>give a failhigh anyway. >>> >>>Ideal for the PV is splitting at realply == 2 and ideal for all non-pv moves is >>>doing parallel search at realply == 3. >>> >>>Best regards, >>>Vincent >> >>Except for critical cases. Such as changing your best root move. Splitting at >>ply=3 >>will be bad there in as many cases as it is good. Not splitting at ply-2 there >>will be >>bad in as many cases as it is good.. >> > >you can predict that better than for the root. No you can't. You _always_ have to search every move at the root. that is the _only_ node where you can make that statement. Any other node might not need to be searched completely due to either beta cutoffs where expected, or poor move ordering producing a beta cutoff where it isn't expected. But at the root, you will search every branch, period. > >> >> >> >>> >>>>Tony >>>> >>>>> >>>>>> >>>>>>When that happens, your testresults indicate that's it's better to split lower >>>>>>than to search 2 rootmoves parallel in order to get an established score asap ? >>>>>>( So not breaking off seacrh when 1 gets a first failhigh, but only when the >>>>>>score is resolved ) >>>>>> >>>>>>Tony >>>>>> >>>>>>> >>>>>>> >>>>>>>>
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.