Author: Dieter Buerssner
Date: 10:13:03 05/18/03
Go up one level in this thread
On May 18, 2003 at 12:45:43, Ulrich Tuerke wrote:
>On May 18, 2003 at 11:48:40, Robert Hyatt wrote:
>
>>On May 17, 2003 at 14:35:43, Ulrich Tuerke wrote:
>>
>>>>
>>>>BTW. I started to change for one counter as an experiment (the normal node
>>>>counter), and used unsigned long long and double. The funny result: with both
>>>>methods, the program ran reproducably 0.5% faster ...
>>>>
>>>Are you telling when replacing "unsigned long" for the type of the node-count
>>>variable by "long long" or "double", then your program would run faster ?
>>>
>>>I guess, I got this wrong. Did I, Dieter ?
No, you didn't get it wrong.
>>This sometimes happens. Because of some serendipity thrown into the equation
>>by additional instructions needed to handle the extra 32 bits + the carry
>>operation. It is not uncommon to simply move a piece of code around and notice
>>a change in speed (sometimes faster, sometimes slower).
>
>This seems to be true. Nevertheless, I am a bit surprised in this case.
Me, too. I have given up to understand all such seemingly random speed
fluctuations that can be caused by a small code change, that really should not
influence the speed in the way seen.
>Switching to 64 bit variables probably means that extra code will be required on
>assembler level (because of the 32 bit word size). So, it's not just "moving a
>piece of code around" but having additional code (as you have already
>mentioned).
>It seems more difficult on modern architectures to predict the influence of a
>code change on performance - perhaps because of thinks like pipelining, done by
>the processors.
I agree. There are also some subtle things, that are basically out of control.
Using a 64-bit var may need a function call for things, that don't need function
calls for a 32 bit type (although, this probably is not the case in this
specific example). When the compiler sees the function call, it may need to
allocate the registers differently. By luck, it could be more efficient. The
function call might be outside of an inner loop where all the work is done, but
could still influence it.
In one version of my engine with one compiler I saw, that when searching a
position in "epd-testsuite-mode" it ran 5% faster than when searching it after a
"go". Just unexplainable. All the work is done exactly the same way. The same
outer-level search function is called.
Now and then, I had seen, that adding some debug code
if (condition that is rarely if ever true)
printf("some info\n");
made the program faster (very slightly but significantly and reproducable).
Linking order has a to me uncontrollable looking influence on the speed,
sometimes (several percent). Doing small changes, and the fast looking linking
order doesn't look as good anymore.
I just accept such things now, and more or less ignore it.
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.