Author: Gerd Isenberg
Date: 01:52:15 08/23/03
Go up one level in this thread
On August 22, 2003 at 18:23:19, Uri Blass wrote:
>On August 22, 2003 at 17:05:31, Gerd Isenberg wrote:
>
>>On August 22, 2003 at 16:02:56, Uri Blass wrote:
>>
>>>I have many cases when I want to do something for all the 1's of a number that
>>>is
>>>0-255
>>
>>This nice range needs simply a switch or a function pointer array.
>>
>>>
>>>I do something like this if I am sure that the number is not 0(I start with
>>>while if the number can be 0)
>>>
>>>do
>>>{
>>> j=smallest_power[i];
>>>/*for example smallest_power[34]=1 because 34=2^1+2^5 and 1 is the smallest
>>>power in this representation*/
>>> f(j);
>>> i&=i-1;
>>>}
>>>while (i>0);
>>
>>hopefully "i" is unsigned. I would prefere
>>while (i!=0);
>>
>>>
>>>I believe that it is not optimal because I calculate information that I do not
>>>need and it is better to have something like
>>
>>So you don't need the bit index but only the pop count and n'th bit?
>>
>>>
>>>for (k=0;k<weight[i];k++)
>>>f(power[i][k]);
>>>
>>
>>I would avoid the loop here. But wasn't there a similar discussion recently?
>>
>> simple();
>> andrew();
>> tim();
>> heiner();
>> reinhard();
>> switch256();
>> funcp();
>
>I remember but it was a different case and I got a decision there to use
>some if's
>if (dirnow&192)
>{
> if (dirnow&128)
> {
> }
> if (dirnow&64)
> {
> }
>}
>if (dirnow&63)
>{
>}
>
>In the cases that I used it at that time usually there were only few 1's and now
>there are usually more 1's so I do not like if's because there are more if that
>the program needs to do.
>
>I can maybe use
>switch that is not switch 256 because the number of possibilities is smaller.
>
>when i is directions of the king then there are less cases
>basically 4 corners
>8 squares near the corner
>4 type of squares in the first rank or first file and other squares so I have
>only 17 cases.
>
>Note that people always push me for assembler and I want to see what I can
>improve by simple logic that is independent of assembler.
>
>The problem here is also that I want to save the value of i to use it later and
>the original solution when I change the value of i does not give me it.
>
>I decided that I do not like long code so I reject the switch solution.
>I am afraid that long code may cause problems later even if it is slightly
>faster and when I add more code the thing that was faster is suddenly going to
>become slower.
>
>I feel that the code that i have do things that I do not need because I need to
>save a copy of i.
>
>This was the reason that I thought about the alternative that one of its
>advantages is that I do not need to do it
>
>for (k=0;k<weight[i];k++)
>f(power[i][k]);
>
>Uri
I see, but instead of saving "i" (may be only a register/register mov), you have
an additional [256][8] table. Anyway, if this is a hotspot and function "f" is
cheap you may consider loop unrolling, even with inlined "f". If the order of
"k" doesn't matter, in that way:
switch (weight[i])
{
case 8: f(power[i][7]);
case 7: f(power[i][6]);
case 6: f(power[i][5]);
case 5: f(power[i][4]);
case 4: f(power[i][3]);
case 3: f(power[i][2]);
case 2: f(power[i][1]);
case 1: f(power[i][0]);
case 0: break;
}
with MSC you may add a default case with assume(0).
Gerd
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.