Author: Gerd Isenberg
Date: 13:15:26 08/08/03
Go up one level in this thread
On August 07, 2003 at 23:48:51, Vincent Diepeveen wrote:
>You guys can figure out the rest i bet seeing this code.
>
>All that bitboard idiocy always. This kicks the hell out of it.
>
>Vincent Diepeveen,
<snip>
Vincent,
after a first look to your Move generator - i see nothing special or
sensational. A simple and clean straight foreward approach, without any kind of
move ordering considering target squares i guess. An outer loop over all members
of a piecelist, calling inlined GenMovesI for a square of each piece.
In GenMovesI after getting the piece from board, there is first a pawn case and
second a none pawn case, i guess one or two miss predictions per piecelist.
In pawn case you have one outer if !promotion else promotion
Btw. if your row function is unsigned, it may cheaper to ask:
if( (row(u)-1) < (7-1) )
In the none promotion case you have three or four further ifs.
The double push combined with boolean and.
The promotion part has obviously three additional ifs.
In the piece case you distinguish between sliding pieces and none sliding
pieces. One case where missprediction is likely, even if your piecelist is
sorted in ascending piece order.
In both cases you have a do-while loop with one if (color[u] != side) inside.
I understand that the critical inner branches are most often predicted correctly
with color[u]. But anyway i don't like it in inner loops - even correct
predicted branches take some time due to cmp and jxx instructions.
And obviously you loop over all targets, occupied by own pawns and pieces.
Simply not necessary work for pieces defending some pawns and other pieces.
And the additional inner "if" may blow up your loop bodies about some cache line
boundaries...
I learned, that it is better to put loop invariant conditions (not the case
here, but a kind of due to correct prediction) outside the loop and to keep the
loop bodies brancheless.
Ok, i see the problem with bitboard traversal several piece and target subsets
with special exclusive source/target properties via bitscan. They are most often
low populated or empty and the while condition fails quite soon.
But after bitscanAndReset one can already calculate the while condition before
the loop body occurs, which may also be helpfull to predict correctly postbody.
Have you ever tried conditional write?
if( color[u] == xside ) {
rb->zetend->zet = zet;
rb->zetend++;
rb->zetend->zet = zet;
rb->zetend += ( color[u] == xside );
Regards,
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.