Author: Robert Hyatt
Date: 17:00:08 11/23/98
Go up one level in this thread
On November 23, 1998 at 17:52:55, Bas Hamstra wrote: >On November 23, 1998 at 09:26:42, Robert Hyatt wrote: > >>On November 22, 1998 at 16:40:57, Bas Hamstra wrote: >> >>>A few qestions for the more experienced: >>> >>>First a short explanation of what I am doing. I made a movegenerator that >>>generates 1 move at a time. My board is such that each square contains a 32 >>>bit field that indicates by which (uniquely identified) pieces of both >>>colors that square is attacked. Example: >>> >>> A square that is attacked by all pieces would hve all attack bits set as >>>follows: >>> >>> KQRRBBNNPPPPPPPPkqrrbbnnpppppppp = 32 bits >>> >>>During make/unmake I incrementally update the attacks. To get the first >>>capture, I get look at the most valuable enemy piece and with LastOne I get >>>the least costly attacker. It works ok so far. >>> >>>Further: >>> >>>- simple alpha beta >>>- qsearch >>>- only material eval (also incremental) >>>- Move order is a) Caps, sortof MVV/LVA b) Killer c) Rest >>> >>>Thats about the whole program now. >>> >>>Now the questions: >>> >>>1. During iterations the NPS count varies wildly. Look at this (ply >>>iterations for the SAME position): >>> >>> ply 7: 106.000 NPS >>> ply 8: 43.000 NPS >>> ply 9: 93.000 NPS >>> ply 10: 40.000 NPS >>> >>>Note that I *reset* the node counters for each iteration. Why in the world >>>is the NPS at odd plies twice as high??? My profiler indicates most time is >>>spent in updating attacks during make/unmake. >>> >>>2. When I play a few more moves on the board, the qsearch explodes, up >>>till 300% of normal nodes. How can I prevent that? >>> >>>3. According to Vincent Diepeveen incremental movegeneration=good idea >>>BUT incremental attack updating=BAD idea. Would NPS go up if I did *not* do >>>attacks incrementally during make/unmake? >>> >>> >>>Thanks in advance, >>> >>>Bas Hamstra. >> >> >>I answered this on r.g.c.c, but assume you didn't see it there. This is a >>normal issue in alpha/beta, when you don't do any sort of extensions or early >>depth reductions. IE when you search nearly every move to the same fixed >>depth. >> >>Here's what happens: >> >>on even depth searches, you only look at *one* move for positions that end on >>the even plies, which includes the *last* ply at the tip of the branches. You >>do look at every move at odd plies, but this will never include the *last* >>ply since we are doing an even-ply iteration. >> >>on odd depth searches, you look at *every* move for positions that end on odd >>plies, and now this includes the last ply as well. >> >>Knowing that the last ply has more positions than any other ply, when you only >>look at one move there, you waste all your setup code, plus the code to generate >>all the moves (if you do that) and so forth. And then you only search one move >>and exit. If you search to an odd depth, you absorb all that overhead but you >>search every move, which means the time spent in setup and move generation is >>spread over all the moves, rather than just one move. So your NPS jumps up. > >[about posting twice] It was my impatience. Sorry about that. Bob, after some >testing incremental move generating is very fast. But to generate 1 good MVV/LVA >capture really fast is a lot harder. And in more complex positions there appear >more and more captures... NPS goes down :( > >Problem is I never finish anything. Start totally over. And again. A bit too >perfectionistic, I'm afraid. So far I can say that the incremental FROM attack >updates are maybe not the best idea. An older version with a full capture stage >generation was faster. > >*Sigh* > >Next thing I'll try is KEEP the incremental move gen (for the time being :) >but without incremental attack updates. Also I happen to like attack-from tables >over bitboards, because they seem more valuable to me at eval time. > >BTW your hint concerning qsearch limiting worked reasonably well, but still a >qnode percentage of (peek) 200% sometimes. > > >Bas Hamstra. Just remember to count the nodes "right." We had a big problem a couple of years ago discussing this with Ed, because we had a different concept of what a "qsearch" node is. IE if you are doing a 6 ply search, you will get to ply=7 as a call to quiesce(). But *that* call represents a "leaf" position and is *not* optional. If you count that as a qsearch node your total qsearch nodes *must* be larger than your basic search every time, because for every basic search node at the last ply you will get a q-search node that you really can't avoid... Most now call them internal, leaf, and quiescence nodes. doing this your quiescence nodes should be a small fraction of total nodes... except for a few rare cases of course...
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.