Author: Uri Blass
Date: 05:31:30 06/24/04
Go up one level in this thread
On June 24, 2004 at 07:50:33, Anthony Cozzie 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. >>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. > >OK, in general I agree with Knuth: premature optimization is the root of all >evil. > >*HOWEVER* > >1. My program has _never_ been more than 3x slower than Crafty. It is about 1/2 >the speed of crafty right now, and I do a number of things that Crafty doesn't >which slow me down. If Russell is 10x slower, he is doing something stupid >somewhere. I think that all programmers do something stupid somewhere(Otherwise their program could play better). I will be more than 10 times slower than Crafty in WCCC because of many stupid things that I do in movei: I can mention 3 stupid things easily 1)not supporting more than one processor 2)having too many global varaibles 3)not having a function to generate only captures(my qsearch is done simply by first generating all moves and later searching for captures). 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.