Author: Robert Hyatt
Date: 19:17:24 12/09/00
Go up one level in this thread
On December 09, 2000 at 15:40:28, Landon Rabern wrote: >On December 09, 2000 at 00:15:43, Robert Hyatt wrote: > >>On December 08, 2000 at 23:13:13, Landon Rabern wrote: >> >>>On December 08, 2000 at 22:22:24, Robert Hyatt wrote: >>> >>>>On December 08, 2000 at 20:41:40, Landon Rabern wrote: >>>> >>>>>On December 08, 2000 at 16:16:01, Robert Hyatt wrote: >>>>> >>>>>>On December 08, 2000 at 13:21:21, Peter Fendrich wrote: >>>>>> >>>>>>>On December 08, 2000 at 13:06:43, Robert Hyatt wrote: >>>>>>> >>>>>>>>On December 08, 2000 at 12:56:09, Peter Fendrich wrote: >>>>>>>> >>>>>>>>>I looking for a measurement for move generation performance. >>>>>>>>> >>>>>>>>>Do you think FH/CountNodes, where FH is number of times the first generated move >>>>>>>>>was a Fail High, is a good measurement? >>>>>>>>>Do you have some other? >>>>>>>>>What's your figures? >>>>>>>>>I get some 50% and I have a feeling it's to low. >>>>>>>>> >>>>>>>>>//Peter >>>>>>>> >>>>>>>> >>>>>>>>The critical statistic I measure in crafty is this: "For any position where >>>>>>>>I 'fail high' (return a score >= beta) what percentage of the time does it >>>>>>>>happen on the _first_ move?" I generally average 92%. Anything over 90% is >>>>>>>>reasonable. Anything less means move ordering needs work. >>>>>>> >>>>>>>OK, it seems logical. I have in princple 3 types of FH: >>>>>>> 1) Hash table (without moving) >>>>>>> 2) Null Move >>>>>>> 3) Ordinary moves (including the hash table move) >>>>>>> >>>>>>>Do you include all these cases? >>>>>>>With only the third case counted I'm well over 90% >>>>>>> >>>>>>>//Peter >>>>>> >>>>>> >>>>>>Only 1 and 3. 2 is done at a different place in the search and doesn't >>>>>>really count in "move ordering". >>>>>> >>>>>>Actually, the way you wrote it, only 3 counts. for 1) you are not searching >>>>>>a move, so that can't be counted. 2) doesn't count either... >>>>> >>>>>I am getting about 80% on this, is this real bad? I am not doing internal >>>>>interative deepening, do you think this will help a lot, or do you think there >>>>>is something else wrong. >>>>> >>>>>I try moves in this order: >>>>> >>>>>hash/pv >>>>>all captures sorted MVV/LVA >>>>>two killers >>>>>3 history scan moves >>>>>the rest >>>>> >>>>> >>>>>Regards, >>>>> >>>>>Landon W. Rabern >>>> >>>> >>>>Your MVV/LVA ordering is probably the culprit. Because you are trying moves >>>>like QxP, even though the pawn is defended... and you try those _before_ you >>>>try the move that will ultimately fail high (a killer or history move). >>>> >>>>I would still expect it to be higher than 80%... but that might be about right >>>>with MVV/LVA. You get some of that back in terms of faster ordering, and you >>>>get some back because the bad captures get cut off quickly by null-move >>>>searches... but it could be better... >>> >>>Ok, I switched to using my SEE to order the moves, but did not do the bad >>>captures last yet(no time yet), just did them all at once, but ordered with SEE. >>> Now I get about 86%-89%. Do you think I should be able to get over 90% by >>>doing bad captures last? >>> >>>Regards, >>> >>>Landon W. Rabern >> >> >>Very possibly... > >Are you counting beta cutoffs in the q-search as well? No... it doesn't make a lot of sense there. I keep the statistic as it is important for parallel search performance. What I do is this: when I fail high at a normal search node, I increment a counter. If the fail high is on the _first_ move tried, I increment a second counter. The closer the second counter gets to the first counter, the better move ordering is...
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.