Author: Omid David Tabibi
Date: 12:54:24 02/19/03
Go up one level in this thread
On February 19, 2003 at 15:50:11, Uri Blass wrote: >On February 19, 2003 at 15:38:53, Omid David Tabibi 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). >> >>But generating random numbers for hash key initializations might cause different >>hash-table overwrites, and thus the total node count might slightly vary on the >>same position and depth. > >I use fixed numbers for hash key initializations. > That's in my todo list since I released Genesis 1.0, and never got the time to do that...! >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.