Author: Sune Fischer
Date: 07:48:59 01/28/02
Go up one level in this thread
On January 28, 2002 at 10:28:32, Marcus Heidkamp wrote: >I am redesigning my move generator, as well. I used rotated bitboards before, >and they were not too slow. Now, I try to do all the move generation in >assembly, but the improvment won't make up the work involved to do so. I found >out that memory performance is a big deal on a PC, just like Prof. Hyatt (maybe >more than) once said here. So I guess, it would be the best, to keep memory >space as low as possible, and reversed bitboard only would increase it. > >One example: I already finished the assembler section of the capture moves for >pawns, knight, and the king. I did as Intel's optimization manual suggested: I >groupt all instructions as 4-1-1 micros-ops, thus to get the highest throughput. >But what the dynamic code analysis showed was devastating. The processor waited >a total of 140 clock cycles to fetch instructions, where only 30 or so were >predicted for the amount of code. The problem was, the processor had to read it >from main memory. No cache was filled. So is it with data. Each piece of data >not in the cache gives huge panalties compared to some additional calculations >using registers. > >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.
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.