Author: Robert Hyatt
Date: 06:26:42 11/23/98
Go up one level in this thread
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.
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.