Author: Dan Newman
Date: 04:12:07 02/01/01
Go up one level in this thread
On February 01, 2001 at 03:36:08, David Rasmussen wrote: >On January 31, 2001 at 07:15:59, Dan Newman wrote: > >>On January 30, 2001 at 06:26:17, David Rasmussen wrote: >> >>It just means I don't use rotated bitboards. I have a bitboard for each >>different piece type (12 bitboards) + occupied square bitboards for each >>color (2) + an occupied square bitboard (1). This means make() and undo() >>are a bit cheaper since I don't have to update rotated bitboards. Also, >>there are a few large data structures (arrays of bitboards) that aren't >>needed as well--so fewer memory hits. >> >>I treat the non-sliding pieces more or less like any other bitboard program, >>but for sliding pieces I occasionally resort to scanning the board. I guess >>it might be thought of as a sort of hybrid of bitboard and mailbox. >> >>I suspect (but don't have any hard data) that this is cheaper than doing >>rotated bitboards, and it's also much simpler to implement. >> >>OTOH, I think Bas (Hamstra) may have switched to rotated bitboards and >>found them to be faster... >> >>-Dan. > >OK, so essentially you don't have any smart way of calculating the attackboard >of sliding pieces?? > >I mean, the normal method of extracting the state of the file, rank or >diagonal, >and using this to quickly calculate an attackboard, cannot be used in a >non-rotated bitboard design. > >Isn't this just worse in all cases compared to rotated bitboards (except for >the >simpler design maybe)? I calculate a "pseudo-attack" bitboard for sliders. (That's a bitboard that has a bit turned on for each enemy piece on which the slider is bearing, ignoring any blocking pieces.) Then I start extracting the coordinates of the "victims". For each such coordinate I test to see if any pieces are blocking the attack using a blocking-mask bitboard which has all the bits turned on for squares that lie between the attacker and victim. If no blockers are there, we have a real victim. I don't think this differs much in cost from rotated bitboards. In some cases it's probably faster (sparse board), in others it's probably slower than rotated bitboards. Even if rotated bitboards happen to be a little faster generating captures, they will certainly slow down make() and undo(). I don't think that it's really easy to figure out which is better, either by reason or by experiment. You can't just count instructions executed--there are memory/cache effects to be considered. Also, the quality of the implementations will vary, and that is likely to have an even bigger effect. So I might add rotated bitboards and find it slows me down--only because of poor design. -Dan.
This page took 0.01 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.