Author: Tom Kerrigan
Date: 10:05:07 06/01/00
Go up one level in this thread
On June 01, 2000 at 09:34:45, Bas Hamstra wrote: >On May 31, 2000 at 18:57:38, Tom Kerrigan wrote: > >>On May 31, 2000 at 18:02:42, Bas Hamstra wrote: >> >>>Tom, >>> >>>I read another thread about Killers and have an opinion on it. >>> >>>- Doing captures separately speeds you up considerably >> >>Depends on what you mean by "considerably." I'm doing a full width search on >>~10% of the nodes that I search. So the speedup that I can expect is >>significantly less than 10%. > >I don't understand. I have distinct functions gencaps and gennoncaps. My >profiler says gencaps is executed 10x as often as noncaps. So indeed 10%, but >that's just an argument to seperate em, no? If you don't have a function that generates captures, you're obviously an idiot. I assumed you were talking about generating moves in stages during the full-width search. >>>- Doing an on the fly legality check for killers speeds you up noticably >> >>Not if you've already generated them. :) > >I do rotated BB's and there generating captures is very much faster than >generating all moves. Maybe in 0x88 the difference is much smaller and so the >gain of on the fly legality check. Generating captures only is obviously also faster with 0x88. But if there's the possibility that you will need to generate all moves, then you might as well generate them all at one time. Maybe generating in stages is a win, but I assume it's a small win and I've just been explaining my rationale. >>>- Doing SEE based pruning of losing captures in the qsearch cuts the number of >>>nodes and improves node/qnode ratio. You don't have to SEE sort for it. I doubt >>>SEE sorting is a winner anyway. >> >>I've used SEE for a long time and I haven't been extremely happy with it. It's >>not in my experimental program. > >Intuitively I also have my doubts, but it seems to work. What exactly don't you >like and what is you alternative? My test scores basically don't go up with SEE. True, the program goes faster, but for every problem that's solved because of increased speed, it seems there's always a problem that the SEE stumbles on. I don't have an alternative to SEE, but I might look into some eventually. >>>- Having the former, you can skip losing captures in the normal search as well >>>with it, and do those later. Improves sorting noticably. >>In my previous programs, using the SEE to order moves had a speedup of 10%. > >I guess you mean the tree gets 10% smaller. Yep, but it is costly and if nps >worsens more than 10% then why do it? Because of the quiescence search pruning. -Tom
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.