Author: Vincent Diepeveen
Date: 06:33:43 06/24/04
Go up one level in this thread
On June 24, 2004 at 08:31:30, Uri Blass wrote: >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). 4) ordering hardware too late 5) having broken your own rule of using 2000 lines of eval code >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.