Author: Gerd Isenberg
Date: 10:08:34 01/18/04
Go up one level in this thread
<snip> >>Due to such state side effects of "complement" or neighboured diagonals, much >>more elements of the huge attack array are addressed than necessary, which may >>yield to more cache pollution. >> >>Your unique diagonal index scheme 0..14 don't has this problem. In Bob's >>approach for diagonals, it may be worth to introduce a second lookup to consider >>the length of the diagonals by not anding with 63 but with >>diaMaskRU[sq] containing values 1,3,7,15,31,63. diaMaskRU[sq] containing values 0,0,1,3,7,15,31,63. > >I did that when I first wrote this code, but after thinking a while, I tried >the current approach and it was slighly faster, but not by much, probably >because it eliminated the extra memory reference to get the diag length... I'll >test it again to see if this is still true however. It might be different with >the smaller tables I now use, as well. You may try to initialize the eight "short" diagonal right shifts with 64 to get always zero states. Occupied state don't cares at all, if length of the ray is less than three ;-) > >One thought to not forget is that what you are doing is an attempt to >reduce cache usage, by not referencing parts of the bishop attacks that >can be avoided by using the precise diag contents. But the L2 is still >going to suck in 64-128 bytes depending on whether you use AMD or Intel, >and since the useful attack information is now "gappy" it isn't clear that >this is really going to save anything. IE if you use the actual diagonal >contents, rather than the 6-bit "super-diagonal" as I currently do, then >you access 1, and skip 63, then access 2 and skip 62, access 4 and skip 60, >etc. But big chunks of that which is skipped still ends up in L2... > <snip>
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.