Author: Gerd Isenberg
Date: 11:06:15 06/24/04
Go up one level in this thread
On June 24, 2004 at 08:53:42, Vincent Diepeveen wrote: >On June 23, 2004 at 21:03:33, Dann Corbit wrote: > >In software design the best approach is to use top down design. > >You propose bottom up design here where you already start with the best >algorithms and all enhancements before the program works. > >I disagree with that. > >First get something going, then optimize parts of it when the program works >fine. > >Bugfree design is more important than your buggy proposal. Sorry Vincent, where is the contradiction with your proposal? 1. Write clear code. 2. Choose good algorithms. 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. > >>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. >>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. >> >>>I also have to disagree with that number, 11%. I just compiled it and ran it >>>through a profiler. Here are the top 20 consumers. Evaluation totals almost 50% >>>of the execution time. However, your point is well taken. Spending a significant >>>amount of time improving MakeMove() and UnmakeMove() wouldn't gain much.
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.