Author: Andrew Dados
Date: 19:58:43 12/05/01
Go up one level in this thread
On December 05, 2001 at 18:52:44, Vincent Diepeveen wrote:
>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.
Not in a real world of msvc++. You'll get to load a value from memory if it is
not in eax,ebx,ecx,edx or esi. Just check any assembler putput of some simple
routines.
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.