Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: making code color independant

Author: William H Rogers

Date: 12:35:46 12/08/03

Go up one level in this thread


On December 08, 2003 at 15:22:11, Russell Reagan wrote:

>On December 08, 2003 at 13:47:36, Heiner Marxen wrote:
>
>>Those small arrays indexed by color (I assume color is 0 or 1),
>>can sometimes be replaced by unconditional expressions, which do not even
>>need a memory reference, by filling small bit groups into a single constant,
>>and shifting out the relevant part:
>>    lastRank[2] ={ 7, 0 }
>>translates to
>>    (0x70 >> (onMove*4)) & 0x0f
>>
>>[ Looks ugly, but somehow I like it :-) ]
>>
>>In this special case we an do even better than the general approach:
>>    (8 - onMove) & 07
>
>But how often will the compiler convert the code to this (or did you mean that
>you should do the optimization yourself?)? I had an optimization in mind once
>that I thought the compiler should have no problem with. Something like:
>
>enum Color { white, black };
>
>inline void ChangeColor ( Color & color )
>{
>    static const Color oppositeColor[2] = { black, white };
>    color = oppositeColor[color];
>}
>
>I had hoped to use an enum in C++ to assure that a Color would always be white
>or black, and I had hoped the compiler would convert it to something like:
>
>color ^= 1;
>
>But it didn't. I tried several. Maybe newer ones like MSVC++ .NET 2003 or the
>Intel compiler will make these kinds of optimizations though. I tried VC++ 6
>(relatively old now), and the newest gcc. What the compiler did was only a
>little slower than if I forced the optimization:
>
>void ChangeColor ( Color & color )
>{
>    color = Color( color ^ 1 );


Try Color = -Color
That should work fine. Just keep track of what color you should be.
Bill

>}
>
>But I'd rather not do that, because it defeats my point of using an enum in the
>first place. And of course, 1% because of something like this isn't going to
>make a difference. I think the other issues like whether or not you can avoid
>conditionals (or make them easily predictable), and avoid memory accesses will
>be the main issues that could make a bigger difference.



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.