Author: Vasik Rajlich
Date: 03:44:19 12/04/04
Go up one level in this thread
On December 03, 2004 at 16:42:53, Gerd Isenberg wrote: ><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. True - completely loopless, completely branchless. > >> >>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. > Ok. The # makes sense - and of course it's impossible to prove anything since you can always question the implementation. >>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. > True. >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. Yes. It's also (usually) easier to implement - which is important if you're still in the experimenting stage. > >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 > >>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.