Author: Robert Hyatt
Date: 17:14:32 05/18/03
Go up one level in this thread
On May 18, 2003 at 16:41:54, Ulrich Tuerke wrote:
>On May 18, 2003 at 13:13:03, Dieter Buerssner wrote:
>
>>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.
>
>This reminds me on something which I had heard about the DarkThought-project
>(Ernst A. Heinz, Markus Gille, (Peter W. Gillgasch)).
>At the beginning of a tournament game, they had used to repeatedly start their
>engine, measuring performance until they were satisfied.
>Obviously, the way of loading the engine into memory can have some effect on
>performance on some platforms. This had been under Digital Unix.
>
>Uli
>
>>
That is a well-known (but different) problem called "cache line aliasing".
When you run a program, it gets loaded into memory and the specific real
pages used affect how the program maps into cache memory. I've seen people
try all sorts of things...
boot, run a database app, then run the chess engine. Boot, run _two_
apps, then run the chess engine. Repeat until you get the NPS you are
looking for, or get sick of it, whichever comes first.
This is solvable by the O/S (I patched linux a couple of years ago to fix
this myself) but it generally is not done for reasons of O/S efficiency. But
it introduces a bit of randomness in the performance that is a pain for those
of us interested in .5 % type numbers. :)
>>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.