Author: Uri Blass
Date: 20:47:20 06/23/04
Go up one level in this thread
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? The example that I understood when I started movei is tscp and tscp is using a lot of global varaibles. 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. 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.01 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.