Author: Vincent Diepeveen
Date: 15:52:44 12/05/01
Go up one level in this thread
On December 05, 2001 at 12:27:36, Ed Schröder wrote:
>On December 05, 2001 at 12:03:49, Dieter Buerssner wrote:
>
>>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
>
>
>A good rule is to define not more that 3-4 integers in a routine.
>
>void routine (void)
>
>{ int x,y,z; // the most used variables in the routine
>
>// do something
>
>}
>
>
>Always use "int", avoid "short" by all means. "char" can be used too but
>realize that this is processor expensive as soon as you are going to index.
>
>It will depend on the quality of the compiler if you can use 4 integers.
>
>Ed
The huge number of registers at nowadays processors which use register
renaming gives the programmers the ability to use loads of variables
which with register renaming will be all in the registers despite what the
assembly code might say.
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.