Author: Robert Hyatt
Date: 17:10:27 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. Get a new book. There are other models that are used as well. > >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. That I will agree with. Optimize after everything works, as before that point, wild changes are likely and they will invalidate early optimizations. > >Bugfree design is more important than your buggy proposal. > >>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.