Project help required: Bitboard Fruit 2.1

Discussion of chess software programming and technical issues.

Moderators: bob, hgm, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
Post Reply
ZirconiumX
Posts: 1327
Joined: Sun Jul 17, 2011 9:14 am

Project help required: Bitboard Fruit 2.1

Post by ZirconiumX » Tue May 08, 2012 3:20 pm

I have the extreme barebones of a bitboard Fruit in the works, however it segfaults on me pretty much all the time.

I use the Umko/DoubleCheck GPLv3 Magic bitboard generator, and this seems to be the problem, as GDB reports that it oddly segfaults at a certain call to bishop_attacks(), coincidence hmmm?

At the moment it is only used for sliding piece mobility evaluation, but I did say extreme barebones.

Now I know that this is extremely ironic, what with the Rybka/Fruit debate, but hey, I get public domain "might have been" snapshots, such as:
Robert Hyatt wrote:

Code: Select all

attacks = bishop_attacks(square);
mob = popcnt(attacks & ~own_pieces);
opening += mob * BishopMobOpening;
endgame += mob * BishopMobEndgame; 
And, oddly, my implementation looks like this:

Code: Select all

	    attacks = bishop_attacks&#40;from,1ULL << from&#41;;

	    mob += population_count&#40;attacks & -board->bitboards&#91;&#40;colour&#41; ? 2 &#58; 1&#93;);

            op&#91;me&#93; += mob * BishopMobOpening;
            eg&#91;me&#93; += mob * BishopMobEndgame;
Yes, I apologise to Fabien Letouzey, and all of the other programming Gods for making it extremely hard to understand, and for breaking the "low memory footprint" ideology (it uses the xxx256 as it appears to be the most commonly used) but basically:

Code: Select all

	    attacks = bishop_attacks&#40;from,1ULL << from&#41;; // Umko bishop magics take &#40;square, bitboard&#41;

	    mob += population_count&#40;attacks & -board->bitboards&#91;COLOUR_IS_BLACK&#40;colour&#41; ? BLACK_PIECES_BB &#58; WHITE_PIECES_BB&#93;);

            op&#91;me&#93; += mob * BishopMobOpening;
            eg&#91;me&#93; += mob * BishopMobEndgame;

Download here.

Matthew:out

Note to mods: watch very carefully.
Some believe in the almighty dollar.

I believe in the almighty printf statement.

bob
Posts: 20912
Joined: Mon Feb 27, 2006 6:30 pm
Location: Birmingham, AL

Re: Project help required: Bitboard Fruit 2.1

Post by bob » Tue May 08, 2012 3:31 pm

ZirconiumX wrote:I have the extreme barebones of a bitboard Fruit in the works, however it segfaults on me pretty much all the time.

I use the Umko/DoubleCheck GPLv3 Magic bitboard generator, and this seems to be the problem, as GDB reports that it oddly segfaults at a certain call to bishop_attacks(), coincidence hmmm?

At the moment it is only used for sliding piece mobility evaluation, but I did say extreme barebones.

Now I know that this is extremely ironic, what with the Rybka/Fruit debate, but hey, I get public domain "might have been" snapshots, such as:
Robert Hyatt wrote:

Code: Select all

attacks = bishop_attacks&#40;square&#41;;
mob = popcnt&#40;attacks & ~own_pieces&#41;;
opening += mob * BishopMobOpening;
endgame += mob * BishopMobEndgame; 
And, oddly, my implementation looks like this:

Code: Select all

	    attacks = bishop_attacks&#40;from,1ULL << from&#41;;

	    mob += population_count&#40;attacks & -board->bitboards&#91;&#40;colour&#41; ? 2 &#58; 1&#93;);

            op&#91;me&#93; += mob * BishopMobOpening;
            eg&#91;me&#93; += mob * BishopMobEndgame;
Yes, I apologise to Fabien Letouzey, and all of the other programming Gods for making it extremely hard to understand, and for breaking the "low memory footprint" ideology (it uses the xxx256 as it appears to be the most commonly used) but basically:

Code: Select all

	    attacks = bishop_attacks&#40;from,1ULL << from&#41;; // Umko bishop magics take &#40;square, bitboard&#41;

	    mob += population_count&#40;attacks & -board->bitboards&#91;COLOUR_IS_BLACK&#40;colour&#41; ? BLACK_PIECES_BB &#58; WHITE_PIECES_BB&#93;);

            op&#91;me&#93; += mob * BishopMobOpening;
            eg&#91;me&#93; += mob * BishopMobEndgame;

Download here.

Matthew:out

Note to mods: watch very carefully.
First, I assume you use the usual black=0, white=1? If so, I don't see the need for the conversion to 1 or 2? C uses array indices of 0 ... N-1, so it would be far more natural, and much easier to read, to do something like

mob = popcnt(attacks);

or

mob = popcnt(attacks & ~occupied[color]) if you want to exclude counting squares that your pieces occupy...

It should be hard for a correct magic generator to segfault, that would likely mean that some of the initializing data was not properly set up...

User avatar
hgm
Posts: 24550
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: Project help required: Bitboard Fruit 2.1

Post by hgm » Tue May 08, 2012 4:12 pm

Interesting. I was considering to make a mailbox version of Ippolit. But I am not sure how 'contaminated' that engine is still considered to be.

ZirconiumX
Posts: 1327
Joined: Sun Jul 17, 2011 9:14 am

Re: Project help required: Bitboard Fruit 2.1

Post by ZirconiumX » Tue May 08, 2012 5:06 pm

Bob (If I may call you that),

sorry, no. Fruit uses White = 0, Black = 1, viz:

Code: Select all

const int White = 0;
const int Black = 1;
So I had to use the awkward, and ugly hack to get that working.

H.G.,

that would be, ermm, interesting.

(I'd take it - I have to use a PowerPC mac, so all the inbedded INTEL macros are damned annoying. (And when you change them to universal macros it segfaults.))

Matthew:out
Some believe in the almighty dollar.

I believe in the almighty printf statement.

syzygy
Posts: 4564
Joined: Tue Feb 28, 2012 10:56 pm

Re: Project help required: Bitboard Fruit 2.1

Post by syzygy » Tue May 08, 2012 6:43 pm

ZirconiumX wrote:Bob (If I may call you that),

sorry, no. Fruit uses White = 0, Black = 1, viz:

Code: Select all

const int White = 0;
const int Black = 1;
So I had to use the awkward, and ugly hack to get that working.
Then put the white pieces in element 0, black pieces in element 1?
Or if you somehow are forced to use element 2 for white, element 1 for black, then use "2 - colour" as index.

Do you realise that attacks = bishop_attacks(from,1ULL << from) gives you a bitboard representing the attacks of a sole bishop on an otherwise empty board? You could as well do bishop_attack(from, 0), since the "1ULL << from" is masked out anyway during the calculations.

The line

Code: Select all

mob += population_count&#40;attacks & -board->bitboards&#91;COLOUR_IS_BLACK&#40;colour&#41; ? BLACK_PIECES_BB &#58; WHITE_PIECES_BB&#93;);
seems to index the board->bitboard[] array by a bitboard, which is bound to crash your program.

User avatar
Evert
Posts: 2929
Joined: Fri Jan 21, 2011 11:42 pm
Location: NL
Contact:

Re: Project help required: Bitboard Fruit 2.1

Post by Evert » Tue May 08, 2012 8:34 pm

ZirconiumX wrote: sorry, no. Fruit uses White = 0, Black = 1, viz:

Code: Select all

const int White = 0;
const int Black = 1;
So I had to use the awkward, and ugly hack to get that working.
I've always found white=0, black=1 to be more intuitive, but apart from that I don't see how it matters one way or the other. Why would you need a "hack" (ugly or otherwise)?

User avatar
hgm
Posts: 24550
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: Project help required: Bitboard Fruit 2.1

Post by hgm » Tue May 08, 2012 8:41 pm

Well, using (x?2:1) when you know x can only be 0 or 1 is always very bad practice, because the compiler might not be smart enough to know that x can only be 0 or 1, and might generate expensive code (with branches) to compute it. While the expression under those conditions is equivalent to x+1 which, when used as an array index, can be optimized away completely. (a[x+1] = (a+1)[x], where a is a constant).

Sven
Posts: 3851
Joined: Thu May 15, 2008 7:57 pm
Location: Berlin, Germany
Full name: Sven Schüle
Contact:

Re: Project help required: Bitboard Fruit 2.1

Post by Sven » Tue May 08, 2012 8:43 pm

Hi Matthew :-)

In your version of move_do.cpp, the way you update your bitboards differs heavily between the functions square_clear() and square_set(). In square_clear() you are using piece_12.

Also, from looking at your changes it is not obvious which of the bitboards you are using for "all empty squares" resp. "all occupied squares".

If the version you offered for download is still up to date regarding the point above then your program will crash due to wrong board updates. This might be a reason for getting a crash at some point in time.

I therefore strongly suggest that you run "perft" tests until your modifications of board representation, make/unmake, attack generation and move generation are working perfectly. Only then I would start looking at the evaluation.

Have you also tried the debug version by compiling with the DEBUG preprocessor switch? That activates the ASSERT macro which is the most powerful debugging tool of the whole Fruit engine. Invalid or inconsistent operations on the board should be found quickly that way.


Finally, please consider to remove "Book.bin" from the archive you offer for download, that reduces its size quite a bit :-)


@Ronald: BLACK_PIECES_BB and WHITE_PIECES_BB are most probably constants with the values 2 and 1 and seem to be meant as indices into the bitboards[] array denoting the "all black pieces" and "all white pieces" bitboards, respectively. So I don't think these are an issue.

Sven

Sven
Posts: 3851
Joined: Thu May 15, 2008 7:57 pm
Location: Berlin, Germany
Full name: Sven Schüle
Contact:

Re: Project help required: Bitboard Fruit 2.1

Post by Sven » Tue May 08, 2012 10:09 pm

You need to convert square numbers that are in the range 0..255 into those in the range 0..63 (using SQUARE_TO_64) before indexing any of the magic_bb_xxx arrays. Maybe you can do this within bishop_attacks(), rook_attacks() etc.

Sven

syzygy
Posts: 4564
Joined: Tue Feb 28, 2012 10:56 pm

Re: Project help required: Bitboard Fruit 2.1

Post by syzygy » Tue May 08, 2012 10:11 pm

Sven Schüle wrote:@Ronald: BLACK_PIECES_BB and WHITE_PIECES_BB are most probably constants with the values 2 and 1 and seem to be meant as indices into the bitboards[] array denoting the "all black pieces" and "all white pieces" bitboards, respectively. So I don't think these are an issue.
If the code runs at all, you must be right ;)

Post Reply