Author: Volker Böhm
Date: 08:25:10 06/25/04
Go up one level in this thread
On June 24, 2004 at 12:25:25, Gerd Isenberg wrote:
>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.
>
>
>I did that color-specific code too but maintainability is an issue here.
>Meanwhile, for a lot of functions i use inlines with actual color parameter and
>access (precalculated) data via color index.
>
> doColorSpecificStuff(color2move);
>
>One may easily duplicate code, e.g. by some conditional compiled macro this way
>
> if ( color2move == white )
> doColorSpecificStuff(white);
> else
> doColorSpecificStuff(black);
>
>and to look from time to time what is actually faster.
>
>If an actual parameter of an inlined function is a compile time constant,
>compiler may be able to optimize the additional register usage away in that
>special inlined incarnation of that function.
>
>Another way to introduce compile time constants is to use integer templates with
>C++ compiler supporting this correctly:
>
> doColorSpecificStuff<int color2move> () {...}
>and to call
>
> if ( color2move == white )
> doColorSpecificStuff<white>();
> else
> doColorSpecificStuff<black>();
>
>
>>
>>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.
I may be wrong but I think the branch does not need to be predicted. The flag
does not change right before the jump. Thus it could be loaded in a register
verry early and the jump target can be calculated very early before the jump is
reached. Thus no prediction needed, no failure thus very fast.
>
>I guess for leaf-nodes e.g. as childs of all nodes, those functions are often
>called with same color in a row for N previous moves. Miss-predictions are
>relative more expensive, if the bodies are really small.
>
>Gerd
>
><snip>
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.