Author: Sune Fischer
Date: 02:38:08 08/14/04
Go up one level in this thread
On August 14, 2004 at 02:40:04, Russell Reagan wrote: >>On August 13, 2004 at 06:01:49, Tord Romstad wrote: > >>>I think it is something that can and should be ignored, until you have a >>>rather strong engine... For a not very strong engine, it is not a bad idea to >>>sacrifice some speed in return for flexibility. > >On August 13, 2004 at 19:48:52, Sune Fischer wrote: > >>I don't think it should be ignored, it's a factor in the equation just like so >>much else. >> >>Wouldn't it be silly to develop a strong 50000 line engine and then have to >>rewrite all of that to a different language? >>When would be a good time to make this conversion, how strong should the engine >>become? > >The way Dann Corbit explained the optimization process to me was the clearest >and most thorough explaination that I've heard. People usually tell you to >ignore optimization until you have something working correctly, but that is only >half of the advice. > >As you pointed out, by the time you have something that works correctly, if you >haven't planned for optimization, you will have rigid code. It will be difficult >and painful to optimize effectively. You have to plan ahead. > >So how do you plan for optimization? You don't worry about micro-optimization at >all. Instead you work on a good design that will allow you to be highly flexible >when it is time to optimize. This way, even if what you currently have is slow, >if you have written code that is modular and encapsulated, you will be able to >make changes without too much work and optimize effectively. > >What Tord said above is very ironic :) He said, "For a not very strong engine, >it is not a bad idea to sacrifice some speed in return for flexibility." The >ironic part is that by sacrificing speed for flexibility, you allow yourself >much better optimization opportunities later on, so you aren't really >sacrificing speed in the end. > >Here is Dann's advice. > >1. Write clear code. >2. Choose good algorithms. >3. Write abstract code that hides the implementation details when possible. >4. When everything works well, profile it. >5. Speed up the stuff that will benefit from it. > >I think it makes a lot of sense. If you do 1 and 3, you will have flexible code. >If you have flexible code, you can do 2 very easily, switching algorithms >without much headache. After you profile it, if you have flexible code, you will >be able to make changes easier to speed things up. In the end you have a fast >program that is also solidly written. There is one thing I don't like about this approach, I'd be sitting with the knowledge that a program like this would have to be rewritten entirely at some point. If you know you're eventually going to do everything all over again you are more likely to begin writing spagetti. Also the mere thought of having to redo a large piece of code would make me less willing to put in some real effort now. For example, I currently have a lot of small utility functions optimized with tables and floodfillers for e.g. pawn-king races. They took a long time to write and debug, but they only had to be written once then you can forget all about them. How I use these in the evaluation and algorithms is of course subject to change many times. The point is, I would not have bothered to do that if I had know it was just a quick and dirty piece of testing code I was working on. -S.
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.