Author: Uri Blass
Date: 08:15:50 06/24/04
Go up one level in this thread
On June 24, 2004 at 09:33:43, Vincent Diepeveen wrote: >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 I do not think that I broke that rule. I also has a different definition of that rule and I include only lines of functions. I do not include tables of numbers as part of the evaluation code inspite of the fact that the program is using the numbers. I think that even with these tables I have less than 2000 lines but I did not count. I will probably use athlon3000 in the beginning of the tournament and may upgrade later to opteron. 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.