Author: Gerd Isenberg
Date: 06:47:55 05/05/04
Go up one level in this thread
On May 05, 2004 at 07:26:40, Vincent Diepeveen wrote: >On May 05, 2004 at 06:52:06, Gerd Isenberg wrote: > >With bitboards perhaps it's slower. Ok, for rotated bitboards or rotated indicies there is only the need to update more or less the four rotated occupied bitboards (despite hash, and piece bitboards, move50 and some other stuff, like redundant board representation and castle and ep flags). getAttackesFrom(rook/bishop) requires two rotated lookups, getAttackedBy(sq) requires four sliding lookups. Since those lookups are relative cheap, incremental attack update is no issue with rotated bitboards. With fill-based attack generation there is only one occupied bitboard. My idea with fill-stuff is, as long you have some sliders on the board, to do some unconditional instructions chains, to gain from todays superpipelined processors and to collect as many disjoint sliding attack data as possible. > >Also in endgames with non bitboards it's faster. > >It's not trivial to implement however. Yes, my former dos-program had this incremental updated piecesets[64], 32-bit words for each square and redundant bitboards[32] for each possible piece. And, probably a bit too much, even incremental updated en prise information and a lot of more stuff. Gerd > >>On May 05, 2004 at 03:03:15, Daniel Shawul wrote: >> >>>Hello >>> >>>Is incremental attack table slower than creating them on fly? >>>I have both versions working properly right now but the incremental >>>one further drops NPS by 30% , though InCheck and Checks are for free in this >>>case. Anybody have similar experience? I am sure i have made no mistake in >>>updating because i checked it with the known perft positions and node count is >>>perfect. >>> >>>best >>>daniel >> >> >>Incremental attack table update in one stage has probably (depending on your >>design and structures) the drawback, that it is done in make/unmake, even if >>those moves result in "lazy" (leaf) nodes, where most attack information is not >>needed at all. >> >>Another aspect with incremental attacks is that the amount of work depends on >>the number of squares with changed controls. So IMHO programs that do >>incremental attack generation probably become relative weaker in some endings >>with sliding pieces. >> >>Gerd
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.