Author: Peter Rosendahl
Date: 07:31:19 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;
>};
Actually the correct way to do it, would have been to return a reference
like
Bitboard& operator &= (const Bitboard& b)
(see "Effective C++" item 15). But I don't use any things like
(b1 = b2) = b3; // possible with built-in types
in Resp, so I guess I get away with that ;)
>
>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.
I didn't think there is a huge impact on speed. In older versions of
Resp I used the C approach, but later added the wrapper in order to
clean up the code a bit (popcount, msb, lsb, ... went into class Bitboard).
I tested under MSVC and didn't measure a big difference.
>
>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
I just made a little test using gcc 3.01 and after changing
one single line ...
to_set &= freeSquares; // 1)
to
to_set.bits &= freeSquares.bits // 2) [access modifier changed to public]
... I compared assembly output. gcc produced two additional mov instructions for
1), so it's possible the optimizer cannot catch this (compiled with O2).
After that I started a little performance test:
return type Bitboard --> Perft 6 = 77.323
return type Bitboard& --> Perft 6 = 75.944
return type void --> Perft 6 = 74.379
[Linux mylinux 2.4.4-4GB #1 Wed May 16 00:37:55 GMT 2001 i686 unknown]
I don't know about the Windows/MSVC version, but for Linux/gcc using void (or
not using operators at all) might be a good idea; thanks for bringing that up :)
Peter
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.