Author: Gerd Isenberg
Date: 13:42:53 12/03/04
Go up one level in this thread
<snip> >>>2) Do you really need a separate entry for white rook 1 and white rook 2? You >>>could give both of them the same bit sequence - this would also get rid of the >>>problems with >2 rooks or >1 queen. >> >>I know, but there is one problem with multiple rooks, i like to avoid - to find >>the source square, where a rook sits, from a given target square the rook >>attacks, since more than one rook may share the same rank or file. >> >>Steffan's solution is to do an additional fill in the opposite direction: >> >>http://chessprogramming.org/cccsearch/ccc.php?art_id=266676 >> >>Therefore i like to get disjoint attacks for most common cases: >> >>rook1 = rooks & -rooks; // lsb >>rooks2 = rooks & (rooks-1); // most often popcount(rooks2) < 2 >> >>Only if popcount(rooks2) is greater one, i have to do it in Steffan's way. >>Same for > 1 queen or > 1 equal colored bishops. > >Aha. Yes, Steffan's solution seems a bit expensive. Yes, but very consistent and clear. No loops traversing pieces. No bitscans. All on the fly if required. > >Actually, it seems that for cases where you need attacks from one specific >square, the table lookups would be more attractive. > Yes, it will be hard to beat rotated bitboards - specially with pseudo legal movegen. After 1/1 replacement of rotated with mmx-fillroutines i had a slowdown of about 1-2% in my program. Due to my former design with legal move generation, some routines like getting all taboo squares for king to move and detecting pinned pieces, a succesive replacement of dedicated routines finally resulted in a slight speedup. Most likely a "mixed" approach as you suggest would be faster, because i still had bitscan (and later 1<<sq) in a "classical" bitboard traverse loops, but i didn't try it. >The filling approach seems naturally suited for tasks where you deal with true >multibit board regions and have no intention to pull the bits out one by one. >This means the various mobility-in-x, etc - with nested calls, and all sorts of >interesting masks used to do the occlusions. > Yes. <snip> >>I guess the whole stuff only makes sense if that very often used memory is >>"allways" in L1-data cache... > >Now that's really low-level! The nice thing about ignoring it is - every year >the compilers get closer to what can be done hand-tuned. :) > Yes. Nowadays it becomes harder and harder to outperform compiler. OTOH the design of your data structures and whether to keep search related data in an array[ply], like implicite or explicite stacks, or to keep data temporary in an area shared by all "plies" is still your decision - i guess. Same problem with calculating on the fly, probably multiple times, versus storing/caching data for (far) later use. Calculating on the fly has some merits. In rotated lookups as well in Steffan's calling fill-routines when required. Here my "intention" is to have a kind of fast "register file" in the L1-cache with 128 bitboards (or a few more) shared by each node. >Anyway - thanks for the fascinating bitboard lesson. Someday when computer chess >is a mainstream sport you can write a bestseller :) > LOL - a mainstream sport, god forbid ;) May be the whole stuff sucks! Thank you too for your patience and the enjoyable thread. Gerd >Vas >
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.