Author: Vincent Diepeveen
Date: 03:23:18 12/06/01
Go up one level in this thread
On December 05, 2001 at 22:58:43, Andrew Dados wrote:
>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.
you also tried with sp4 + processor pack?
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.