Author: Russell Reagan
Date: 23:40:04 08/13/04
Go up one level in this thread
>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.
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.