Author: Uri Blass
Date: 13:16:47 02/19/03
Go up one level in this thread
On February 19, 2003 at 15:10:43, Dann Corbit wrote: >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. The point is that often knowledge is more important than tablebases. See the following position when Movei missed a draw against Hagrid. A lot of programs solve it faster without tablebases. http://www.f11.parsimony.net/forum16635/messages/42875.htm > >If you are talking about 13 or so chessmen, then maybe you and I were talking >about the same idea but with different terms. Here are some examples from Leo's tournament and I think that tablebases are not needed to get more points(at least in the case of the game against Hagrid tablebases could not help to avoid the mistake and I believe that the same for part of the other cases when knolwedge in the evaluation could be always enough to avoid the mitsakes) Movei to play and draw against List [D]7k/8/5R2/8/5K2/P6r/1P6/8 w - - 0 68 Movei to play and lose against Exchess [D]8/p7/1p1k4/2pb4/4n1RP/P7/1P5K/8 b - - 0 47 Movei to play and draw against Exchess [D]8/5r2/5B2/8/6N1/Pk3K2/1P6/8 w - - 0 67 Movei against Resp Re7 destroyed the chances to win. [D]6k1/1R6/4np1P/8/1P6/1r2BK2/8/8 w - - 0 62 > >Do you have taxicab distance tables for pawn races in place? No I know that it is one of the things that I should add. What sort of >information are you missing? I think that mainly evaluating passed pawns relative to both kings. 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.