Author: Gerd Isenberg
Date: 01:04:45 08/18/02
Go up one level in this thread
On August 17, 2002 at 21:27:08, Russell Reagan wrote:
>I was wondering if there is any speed hit in creating a Bitboard class as some
>bitboard engines do, as opposed to using the simple C version. For example, in
>Resp a Bitboard class is used, and I am not sure if it's a good implementation
>(not to imply that it isn't). The author does things like:
>
>class Bitboard {
>// ...
> public:
> FORCEINLINE Bitboard operator &= (const Bitboard& b)
> {
> bits &= b.bits;
> return *this;
> }
> private:
> UINT64 bits;
>};
>
>If all goes well and it is inlined, I would assume this would be equivalent to
>the C approach. My problem is that I don't know if the class approach will add
>any overhead. Will this be any slower than the C approach where there is no
>overhead in doing a bitboard &= x; ? I think the main thing that's bothering me
>is the return statement. I think it's good in general to return something when
>overloading standard operators, but it's not really necessary when using
>bitboards, and if it causes a speed hit, a void Bitboard operator &=... might be
>better.
>
>For example, in James Swafford's program he has a void return type on his
>bitwise operations for his bitboard class, so it makes me wonder...
>
>This is one area that seems like it should be as fast as possible. If it takes
>twice as long to do a bitwise operation on a bitboard (in addition to doing
>64-bit operations on a 32-bit machine), that's going to add up fairly quick I'd
>imagine.
>
>My attempts to test this myself have all failed due to the compiler optimizing
>my code away, so the ASM doesn't tell me much :) So...help!
>
>Russell
If you don't use any virtuals, there is no or only negligible additional
overhead, short functions may be inlined, and sizeof(Bitboard) is stil 8.
Good style that the &= operator returns a value and behaves like same operators
in native scalar types eg. to write "if (bb1 &= bb2)". In x86 cpus only two
additional mov-instructions are necessary to load edx:eax.
It's a matter of taste to encapsulate native scalare types, where all boolean,
shift and arithmetic operators are already available as fast intrinsics. I
personally prefere to do it not.
Gerd
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.