Author: Uri Blass
Date: 22:55:55 02/19/03
Go up one level in this thread
On February 19, 2003 at 20:00:34, David Rasmussen wrote: >On February 19, 2003 at 14:13:47, Uri Blass wrote: > >>On February 19, 2003 at 13:57:41, Dann Corbit wrote: >> >>>When you want to make your code faster, the most important thing is to find out >>>where it is slow. I don't know how familiar you are with profiling, but a good >>>profiler will show you a lot about your algorithms. On most programs, and >>>certaintly for chess programs, most of the time will be dominated by a few hot >>>spots. If you spend the effort on the hot spots, it will be enormously more >>>beneficial than in other places. >>> >>>Nuts and bolts tweaky sorts of things are fun to learn. But an adjustment to >>>the fundamental algorithm (if it is possible) is often dominatingly better than >>>that. >>> >>>So, my steps to make something faster are like this: >>>1. Profile to find the slow spots. >>>2. Examine and understand the algorithms in the slow places >>>3. Look for a better algorithm >>>4. If a better algorithm exists, try it >>>5. If a better algorithm does not exist, try to improve the existing algorithm >>>6. If still a slow spot, resort to tweaky sorts of things and inline assembly. >>> >>>One idea that is often helpful is to precompute as much as possible, and store >>>the results in a compact lookup table. Then the complex calculation becomes a >>>simple lookup. >> >>I know it. >> >>The point is that the better algorithm that I have is to write similiar >>functions to the functions that I have and when I write similiar functions I >>also think of optimizing the previous functions. >> >>Today I have not a function to generate only captures and I need to do it but it >>leads me to think again about my move generator and I find ideas that can do it >>faster. >> >>I do not do the things that will help most to the speed of my program >>because they may take time and I prefer first to see what I can improve >>relatively fast. >> >>I also think that evaluation of endgames is more important but I like more doing >>Movei faster because it is easier to test for bugs(if I get the same number of >>nodes then I know that I probably have no bugs). >> >>Uri > >This is exactly why you should focus on a good design first, and on speed later. >Early optimization is the root of all evil, Knuth said! > >/David I do not think that there is a contradiction here. The tasks seem to me independent tasks. optimizing is done in the move generator improving the program without doing it faster can be done by 1)better evaluation 2)collecting more information in the move generator in order to evaluate more things. I think about optimizing some parts because if I do not do it now then it means that in the future I will need to change more code in order to do it. The optimization that I think to add is based on adding 2 functions 1)a function to generate only captures and count legal moves. 2)a function to generate only captures and checks and count legal moves. counting legal moves is important for me because I use this information in the evaluation. I believe that generating captures and checks and counting legal moves is clearly faster than generating the legal moves and checking for everyone of them if it is a check but in this function I need to call my functions to put moves in the stack so I prefer to improve the speed of that function first. 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.