Author: Dann Corbit
Date: 16:15:21 06/23/04
Go up one level in this thread
On June 23, 2004 at 18:30:57, Russell Reagan wrote:
>I am curious about a few design choices in Crafty. Some of the questions are
>general questions that anyone who is knowledgable could answer, so I ask this
>publicly instead of via email to Dr. Hyatt.
>
>First issue. Crafty is written with a lot of color-specific code, like:
>
>if (wtm) {
> // ...
>}
>else {
> // ...
>}
>
>This is what I think. The downside to this approach is that you double the size
>of the code, which is not cache friendly. This should be a bigger problem in a
>rotated bitboard engine where there are already cache issues.
You could always score from white's point of view, and return -score for black.
There are two issues here. One is doing things generically, and the other is
doing things as fast as possible.
For instance, I could have a truly generic piece scoring routine like this:
int score_piece(int piece_type, int piece_color);
but then in the code you would see lots of switches and if-tests all over the
place.
I could also have a routine for each type:
int score_pawns(int color);
but then you will see:
if (color == WHITE) ...
all over the place.
I can also have hardwired scoring routines that are very specific:
int score_black_pawns();
but then I will have duplication of code. There are also some gotchas for going
generic.
For instace, I can't reuse a pawn scoring routine like this:
wp_score = score_pawns(Board->WhitePawnBitmap);
bp_score = score_pawns(Board->BlackPawnBitmap);
because pawns go in different directions, have different e.p. vulnerabilities,
etc. depending upon their color.
So no matter what you do, there will be trade-offs and complications.
>Another potential downside is that you introduce an extra branch. However, I
>think that this branch would be easily predictable, since the side to move will
>alternate back and forth, and so the branch decision will alternate.
>
>So it seems that as long as you don't overuse this method and ruin the cache,
>this is a good method as far as speed is concerned. However, I think it is nicer
>to have a single function that works for both colors. It is less to maintain,
>and less error prone.
>
>Second issue. Crafty uses a lot of switch statements, using special code for
>each case, increasing the code size. Same issues. Could be bad on cache, harder
>to maintain. Crafty uses a lot of switch statements to determine the type of a
>piece and update the appropriate bitboard. What about having an array of
>bitboards, indexed by the type of the piece? There are no branches involved, and
>the code is much smaller.
>
>I'd like to know what people think about these design choices. Obviously they
>work well for Dr. Hyatt, but I wonder if alternatives would be better choices
>that would be faster or less error prone.
It used to be that an array of function pointers was dramatically faster than a
big switch. The latest generation of compilers renders the difference as very
small.
I think it is far more important to code in a clear manner that expresses what
you want to do in the most transparent way than to gain 5% by some tweaky trick.
Next year, the tweaky trick might even make it slower when a new generation of
compilers comes out.
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.