Author: Dann Corbit
Date: 12:10:43 02/19/03
Go up one level in this thread
On February 19, 2003 at 14:38:36, Uri Blass wrote: >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. When there are ten pieces left on the board, you will get a very large number of tablebase hits at slow time controls. If you are talking about 13 or so chessmen, then maybe you and I were talking about the same idea but with different terms. Do you have taxicab distance tables for pawn races in place? What sort of information are you missing?
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.