Author: Volker Böhm
Date: 08:51:01 06/25/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 10 Times, are you sure???? In My experience it´s got even 3 times faster (with no eval but material) for the following reasons: 1. Incremental attack tables need an "undo". Thus allways changing the attack-tables twice for every move (copying the attack tables is a little slower). 2. Many moves are made by pieces that may move very much (example queen). When I move a queen I have to remove it´s attack to 8 direction, move it and add it to 8 direction. Is your factor "10" tested or just an opinon? If it is tested I would like to get a idea how you update your attack-tables that fast - perhaps you can tell me. I get about 1,2 million nodes per second on a celeron 1,3 GHZ in a complex situation with a perft search (building attack-tables incrementally and all other "set-move stuff" as zorbrix - keys, piece-tables, material sum, ...). >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 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.