Author: José Carlos
Date: 00:38:35 06/24/04
Go up one level in this thread
On June 24, 2004 at 00:59:01, Uri Blass wrote:
>On June 24, 2004 at 00:01:45, Dann Corbit wrote:
>
>>On June 23, 2004 at 23:47:20, Uri Blass wrote:
>>
>>>On June 23, 2004 at 21:03:33, Dann Corbit wrote:
>>>
>>>>On June 23, 2004 at 20:54:24, Russell Reagan wrote:
>>>>
>>>>>On June 23, 2004 at 19:52:45, Ed Trice wrote:
>>>>>
>>>>>>If you profile Crafty, you will find something like only 11% of the computation
>>>>>>is spent on the evaluation routine. Say you were to make this code execute twice
>>>>>>as fast. Then, overall, the entire program would be only 5.5% faster.
>>>>>>
>>>>>>To make a big performance gain, you have to attack the bottlenecks.
>>>>>
>>>>>
>>>>>I agree with that logic. At the same time, I think it should come with a
>>>>>warning. A lot of times people mistakenly interpret this advice as, "ignore
>>>>>optimization until the program is operational." I think that by doing that, you
>>>>>are placing the upper limit on how fast the program can potentially be much
>>>>>lower than it should be.
>>>>>
>>>>>Let's say I write my program, and I ignore optimization issues early on. The
>>>>>program is now operational, and now I start to work on optimizations. I profile
>>>>>it, hunt down hot spots, and get to the point where there are no obvious
>>>>>bottlenecks. The program is still ten times slower than Crafty. Now what? I am
>>>>>saddled with a poor overall design, and nothing short of a complete rewrite is
>>>>>going to improve the situation.
>>>>
>>>>
>>>>I don't think I have ever disagreed with any post more than I disagree with this
>>>>one.
>>>>;-)
>>>>
>>>>Never, never, never, never optimize a program before it is working correctly.
>>>>And when I say never, I mean not ever.
>>>>
>>>>The only exception to this rule is in the choice of algorithms. There is no
>>>>sense picking a bad algorithm to start with. And even if you did happen to pick
>>>>the wrong algorithm, then it is not hard to change it.
>>>>
>>>>Your advice is bad advice. I hope that nobody listens to it. Permature
>>>>optimization does absurdly more harm than good. For every ounce of benefit,
>>>>there are a trillion gallons of downside. When you start programming ANYTHING,
>>>>including a chess program, write clear, simple code that best expresses the
>>>>algorithm in the most straightforward manner.
>>>>
>>>>Now, let's go farther. Suppose that you have chosen some fundamentally bad data
>>>>structures. If your program is written in an abstract enough manner, it won't
>>>>matter. And the more abstract you make it, the less it will matter.
>>>>
>>>>My point:
>>>>1. Write clear code.
>>>>2. Choose good algorithms.
>>>
>>>I can say that 2 can be divided to the following steps:
>>>
>>>2.1. Write bad algorithm that does the same task as the good algorithm that you
>>>plan but the implementation of it is relatively simple.
>>>
>>>2.2.Improve the bad algorithm.
>>>
>>>I use these 2 steps in my attack tables.
>>>
>>>First I wrote a very slow algorithm to calculate them from scratch and it was
>>>more important for me to prevent bugs and later I used the previous code in
>>>order to help me to debug the program when I changed it to incremental
>>>update(without incremental update movei could probably search more than 10 times
>>>slower than it searches today because having loops for every square on the board
>>>to see if it is attacked from one of 16 directions(8 knight directions and 8
>>>queen directions) after every move is very slow.
>>>
>>>64*16=1024 and it is not all the story because you may need to look for many
>>>squares in some direction only to find that the square is not attacked from that
>>>direction so there are thousands of calculations for every node.
>>>
>>>I even did not consider to write a chess program without that optimization.
>>>
>>>>3. Write abstract code that hides the implementatiion details when possible.
>>>>4. When everything works well, profile it.
>>>>5. Speed up the stuff that will benefit from it.
>>>
>>>What do you suggest about the question of using global varaibles?
>>
>>Global variables are good to have in every program. Examples in C are stdin and
>>stdout, which I suspect you use in your program. However, a variable should be
>>made global if and only if it HAS to be global.
>>
>>Global variables created due to laziness will cause many bad things:
>>1. Evil side effects:
>>int i;
>>int bar(void)
>>{
>> int accum = 0;
>> for (i = 0; i < 5; i++)
>> accum += i;
>>}
>>void foo(void)
>>{
>> int sum_of_sums = 0;
>> for (i = 0; i < 5; i++)
>> sum += bar();
>>}
>
>I do not use varaibles with no meaning like i as a global varaibles.
>
>The question is what about varaibles with clear meaning:
>
>I can give examples:
>1)nodes
>2)ply
>3)hply
>
>The question is also what to do when I add varaibles
A possibly better way to do this is to have a struct with all related data,
for example struct GameData which includes nodes, ply, hply, etc. Then declare a
global variable of that type and use it everywhere. You keep exacly the same
easyness as today, you also add variables easily (inside the struct), and if you
decide to go multithreaded tomorrow, you need only to declare new instances of
one variable. Additionally, you avoid the problem Dann mentioned.
José C.
>I am not going now to change all the global varaibles that I have to local
>before WCCC (no time for it) but I think to add to my evaluation using the phase
>of the game that is defined by the value of pieces of the opponent and to have
>opening evaluation and endgame evaluation instead of one evaluation.
>
>The simplest solution is to add a global varaible and not to calculate it every
>time that I need it or to have it as parameter of some functions because
>I want to have the freedom to use it not only in the evaluation but also in the
>search rules and may decide about some pruning or extension based on the phase
>of the game.
>
>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.