Author: Omid David Tabibi
Date: 08:14:11 07/20/03
Go up one level in this thread
On July 20, 2003 at 10:55:10, Uri Blass wrote:
>On July 20, 2003 at 09:48:39, Omid David Tabibi wrote:
>
>>On July 20, 2003 at 09:36:33, Uri Blass wrote:
>>
>>>On July 20, 2003 at 09:11:35, Ricardo Gibert wrote:
>>>
>>>>On July 20, 2003 at 08:01:50, Uri Blass wrote:
>>>>
>>>>>The question is if there is a way to optimize loops without writing the same
>>>>>commands twice in the code that does the code less readable.
>>>>>
>>>>>I have in some places in movei things like
>>>>>
>>>>>while (i<n)
>>>>>{
>>>>> f(i);
>>>>> i++;
>>>>>}
>>>>>f(n);
>>>>>
>>>>>
>>>>>f is practically some C lines and not a function
>>>>>because I use some local varaibles and giving them to
>>>>>a function may make the program slower.
>>>>>
>>>>>The problem is how to avoid writing the lines of f
>>>>>twice without doing the code slower.
>>>>>
>>>>>The following option is slower because I have also
>>>>>i++ when i=n
>>>>>
>>>>>do
>>>>>{
>>>>> f(i);
>>>>> i++;
>>>>>}
>>>>>while (i<=n);
>>>>>
>>>>>I also thought about the following code but
>>>>>I do not like if commands and I understood it is better
>>>>>to have branchless code.
>>>>>
>>>>>do
>>>>>{
>>>>> f(i);
>>>>> if (i==n)
>>>>> break;
>>>>> i++;
>>>>>}
>>>>>while (1);
>>>>>
>>>>>Uri
>>>>
>>>>Did you profile your code to determine whether optimizing this is worthwhile?
>>>
>>>I guess that maybe I can earn 1-2% speed improvement from optimization of it.
>>>I do not know how to profile my code to find how much I can get from it.
>>>I can find time of functions but it does not tell me the information.
>>
>>Use Intel VTune Performance Analyzer
>>http://www.intel.com/software/products/vtune/ , it has a trial period of one
>>month. Using the "function call" profiling, it provides you with a wealth of
>>information about the efficiency of your functions. I think the old rule of
>>80-20 applies also in computer chess: 80% of the time is spent in 20% of the
>>functions. Finding those 20% and optimizing them can be easier using a profiler.
>
>I know that most of the time is used on the qsearch,makemove and the move
>generator.
>
>I decided to compare simple for in the relevant case and found that it wass
>1/2% slower in the opening position.
>
>I think that I will keep it as for because 1/2% is not a big change.
I think until Movei reaches a +2500 rating strength you should avoid
"over-optimizing" it, i.e., ignore such minute speedups as 0.5% if they result
in a more unreadable code.
In Falcon, I managed to write a highly optimized code, but was finally left with
a highly efficient but disgustingly unreadable code, in which I couldn't
implement a simple idea without working a whole week. During the past months I
have "de-optimized" many parts of the code, turning it into a more readable and
improvable code. Of course this resulted in some performance loss, but I believe
it will be well compensated by the improvements I can make in the more readable
code. (remember that just managing to reduce the effective branching factor from
3 to 2.5 will beat all optimizations.)
One way to deal with optimizations is to highly optimize parts of the code which
you don't modify frequently (e.g., makemove, transposition table, etc), and keep
the other parts simple (e.g., search). But this wasn't feasible for me either,
as I tend to modify the way even the makemove and hash tables work quite
frequently.
>
>Uri
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.