Author: Dieter Buerssner
Date: 09:03:49 12/05/01
Go up one level in this thread
On December 05, 2001 at 05:33:08, Uri Blass wrote:
>In my program I have the following commands when I generate my pin arrays:
>
>if (color(sq)==side)
>{
> pin[sq]=-1;
> d=direction[kingsquare[color(sq)]][sq];
>...
>
>The strange speed demage to my program happens when I try to replace color(sq)
>with side in the last line
>
>color(sq) is more complicated to find then finding side that is simply integer.
>I expected that in the worst case there will be no speed change thanks to
>optimazion of compiler but I did not imagine that my program could run slower
>when I do something simpler.
>
>some data about my program that may help:
>
>
>
>my defs.h file includes
>
>#define color(target) (((info[target])>>3)&3)
>
>
>my data.c file includes
>
>int info[64];
>int side;
>int direction[64][64];
>int kingsquare[2];
>int pin[64];
>
>you can see that calculating color(sq) is not something simple(you need first to
>calculate info[sq] and later to calculate from it the value for color(sq))
Like you, and the others in the followups, I made similar experience. An obvious
optimization slows down the program. I can remember a case, where adding some
debug code (that did not change anything in the search), yielded a speedup of
15%.
I tend to ignore all this, and try to use the most clear, or the supposedly
fastest implementition. The next compile may give different results. On other
computers the results wered different (which is not surprising, either).
As all have mentioned, data/code aligning and cache are obvious possible reasons
for such behaviour.
In your special case, it might be also something else, too. Compilers try to
find out, which variables to put into registers. They have to use some
heuristics to do this. On x86 architectures, only few general purpose registers
are available. You code change means, that side is accessed more often. This may
be enough, to now put side into a register, and use another variable from
memory. But perhaps this other variable was actually more important to keep in
the register. You can check this, by looking at the Assembler outpüt. But I
would suggest, to not look at assembler outputs too often :-) It may cost you
much more time, than anything, that can be gained. And the next compiler version
may do things totally different again.
Regards,
Dieter
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.