Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: optimizing loops question

Author: Uri Blass

Date: 12:03:05 07/20/03

Go up one level in this thread


On July 20, 2003 at 11:14:11, Omid David Tabibi wrote:

>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.)

Yes and I believe that there is a big progress to get there.

>
>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.

I think that I will not care about speed now.

I am in the process of changing the makemove and the main problem is to decide
about the arrays that I want to add.

I hope that I got some idea that I am not going to modify now.

Adding the right arrays can help me to detect some important things fast and I
first think about tactical ideas so I may be slower in nodes per second but the
gain of the possibility to detect fast bad sacrifices even before making them is
bigger.

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.