Author: Heiner Marxen
Date: 12:48:31 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 );
>}
>
>But I'd rather not do that, because it defeats my point of using an enum in the
>first place.
You can switch between 2 values by XORing the XOR of the both values.
What is wrong with
color ^= (white^black);
Is it just that C++ does not let you XOR enums without a cast?
(I do not do C++ myself, just C, so this may show my ignorance)
What _is_ your point of using an enum?
> 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.
Yes, that is the goal.
And there are a lot of places for some of these small functions like
"opposite color of". It may well make a difference.
Of course, tuning the search or eval is much more important, but IMHO
there is some room for these micro-optimizations. Of course, there
should always be some kind of abstraction (macro, function) such that
you write that ugly construct just once.
Cheers,
Heiner
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.