Author: Uri Blass
Date: 11:38:36 02/19/03
Go up one level in this thread
On February 19, 2003 at 14:25:05, Dann Corbit 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. > >You have two good notions here. First, write in a good style to begin with, and >second, to improve the underlying data structures is always a win. > >>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. > >That is a good idea. I think you have a very intelligent approach. You can >also gain a lot from a better compiler. The VC++ .NET compiler or Intel >compiler might add a good bit of speed. > >>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). > >I think evaluation of endgames is not so important. In the late endgame, all >programs except the most primitive do well. The late middle game is where >computers struggle the most, especially if it is a closed position. The program >that solves closed late middle game positions will be much stronger than most >others. Just my opinion of course. > >But for the endgame, just bolt in the tablebase files and be done with it. Movei lost 2-3 points in Leo's tournament because of lack of knowledge in the endgame. Tablebases could not help there because there were enough pawns on the board. 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.