Author: Vincent Diepeveen
Date: 05:43:30 06/24/04
Go up one level in this thread
On June 23, 2004 at 23:04:56, Robert Hyatt wrote:
If you worry about losing a register to that indexing, why don't you worry about
that extra register you lose because you are multithreading?
It is not consequent to use that here as an argument when you already waste a
register to multithreading.
>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.
>>
>>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.
>
>
>It would be nicer. However there may well be a speed penalty since bitboards
>have specific elements for each type and color of piece. As a result it might
>be harder to read.
>
>
>>
>>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.
>
>That would work ok. However the switch is not a performance killer at all, and
>early on it made things easier to change. Turning the bitboards into arrays is
>ok, but then it requires a register to index the arrays and the X86 doesn't have
>many to go around...
>
>
>
>
>
>>
>>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.
>>
>>Thanks,
>>Russell
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.