Author: Sune Fischer
Date: 08:49:39 06/27/02
Go up one level in this thread
On June 27, 2002 at 11:42:35, Robert Hyatt wrote:
>On June 26, 2002 at 04:38:25, Sune Fischer wrote:
>
>>On June 26, 2002 at 02:02:28, Bruce Moreland wrote:
>>
>>>On June 25, 2002 at 05:26:34, Sune Fischer wrote:
>>>
>>>>On June 24, 2002 at 20:33:32, Russell Reagan wrote:
>>>>
>>>>>I am not an experienced bitboard user. I've been thinking about trying them out
>>>>>just to see how they work in comparison with my current 0x88 implementation. Is
>>>>>there any potential problem in mixing the two approaches? One problem that I can
>>>>>see would be that if you have an index for a bitboard, it's not going to index
>>>>>into the same square in your 0x88 array. I suppose the only real reason to keep
>>>>>0x88 would be for efficient edge detection. Do bitboards offer a solution to
>>>>>edge detection? Or do they even need edge detection when using bitboards (ex.
>>>>>using the BSF asm instuction would seem to avoid edge detection altogheter)?
>>>>>
>>>>>Thanks,
>>>>>Russell
>>>>
>>>>For edge detection you can do this:
>>>>
>>>>if (((uint64)1<<square)&0xFF818181818181FF)
>>>> ...
>>>>
>>>>it will tell you when you are on the first and last file or rank.
>>>>I use that in my SEE to raytrace behind the attacking piece, something like
>>>>
>>>>while (!(((uint64)1<<square)&0xFF818181818181FF)) {
>>>> square+=direction;
>>>> if (there-is-an-attacker-on-square)
>>>> add-it-to-the-list-of-attackers
>>>>}
>>>>
>>>
>>>That shift has to be lots of fun for the processor.
>>
>>That is why I really use a Mask[square] table, but for the sake of clarity... :)
>>Anyway I changed it to a macro, so now I can quickly test which is faster, and
>>it seems the Mask[] lookup is faster, for the moment.
>>
>>-S.
>>
>
>If it is faster, I am surprised. IE the shift should run like the blazes
>since there are no memory references (an immediate value of 1, shifted N
>bits avoids memory) while a memory load can be expensive depending on
>whether the mask is in memory, in L1/L2/L3 cache...
>
>That was a common trick on the Cray where _all_ memory references (prior to
>the T90) were real memory accesses (no cache).
To be honest I think I would need a specially designed test to get an answer
here, the overall speed difference is so small that it's just lost in noise.
-S.
>
>>>bruce
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.