Author: Dann Corbit
Date: 21:01:45 06/23/04
Go up one level in this thread
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(); } 2. Harder to maintain, by a landslide. When variables are close to where we use them our comments describe them for us and it is clear what we are doing. For automatic variables, I know that I can modify it in the routine I declared it in, without altering some other routine's use of the same variable like a global. 3. Someday, you may want to multithread. Lord have mercy upon you if you have sprinkled global variables all over the place. There is a time and place for global variables. But it is like goto. Use them only in those rare occasions where they really are a good idea and not a bad one. >The example that I understood when I started movei is tscp and tscp is using a >lot of global varaibles. Yes. For that reason, it is a very painful model if you hope to move ahead into the future. That is why the C++ code I sent you had abstracted them to class members. With class members, you put them into the place where they are used logically, and you prevent global problems from forcing lots of semaphores and critical sections. >If I look at programs like fruit and Crafty then I can see that they get a lot >of varaibles as parameters and do not use a lot of global varaibles. Crafty has no choice. It is a multithreaded program. Fruit is an example of the right way to program. When I saw it, I thought it was beautiful. In truth, it is C masquerading as C++ for the most part (or as Bjarne would say, using C++ as 'a better C'). And so the ideas will translate very well to people who are C programmers only. If anyone has not read the Fruit source code base, by all means go find it and read it. >I thought about it also from optimization point of view >see http://www.talkchess.com/forums/1/message.html?371792 > >In my case I started by writing aloptimization of the algorithm and the point is >that it may be more easy to start with simple stupid algorithm to generate >attack table(calculating big attack tables from scratch with no > >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.