Author: Sune Fischer
Date: 01:38:41 01/29/02
Go up one level in this thread
On January 29, 2002 at 02:51:53, Marcus Heidkamp wrote: >On January 28, 2002 at 10:48:59, Sune Fischer wrote: > >>On January 28, 2002 at 10:28:32, Marcus Heidkamp wrote: >> > >[snipped] > >>>Conclusion: My advice would be to live with as few as possible memory based >>>variables, and reversed bitboards are just too many. >>> >>>Marcus >> >>I agree, but I don't follow. The idea of reversed bitboard is _not_ to use >>lookup tables but instead do some extra operations. >> >>-S. > >As far as I understand the reversed bitboard approach, you need additional >bitboards for the different directions of occupied squares to store the game >position - at least four more bitboards. This will make the move generator >slower, at least, that is what I think. I already try to avoid the lookup tables >like the plague... :-) Yes, I think you need 4 occupied boards, one for each color in both directions. However you also need 4 sets of rotated I believe, and when you update a rotated occupied board you _again_ need to do a lookup. No table lookup is needed for the reversed, the square transformation is so simple: 63-sq. I think all these table lookups for rotated is burning bandwidth at an incredible rate, it is why I think reversed is overall faster. On multiprocessor systems it may be even more significant. >But we should remember that move generation by itself is only a small part of >the total computation time required by a chess engine. I just do the assembler >stuff for fun, it really won't help a lot for the whole engine. > >Marcus That is true, if you already spend 90% of the time in evaluation, this is going to give you nothing in speed. On the other hand it probably won't slow it down either. I think it is simpler to implement and that is a big plus for me. -S.
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.