Author: Robert Hyatt
Date: 08:20:00 06/24/04
Go up one level in this thread
On June 24, 2004 at 08:43:30, Vincent Diepeveen wrote:
>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?
Because the extra register for multithreading is already in use. This would be
a _second_ register... Clear enough?
I took a 3-4% hit when I added the pointer. I don't want to take another that
would probably be bigger.
>
>It is not consequent to use that here as an argument when you already waste a
>register to multithreading.
I have no idea what that means...
it seems to be irrational.
>
>>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.