Author: Bas Hamstra
Date: 14:52:55 11/23/98
Go up one level in this thread
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.
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.