Author: Uri Blass
Date: 17:36:47 05/25/04
Go up one level in this thread
On May 25, 2004 at 19:36:04, Will Singleton wrote: >On May 25, 2004 at 17:44:55, Andrew Wagner wrote: > >>I do a lot of reading through CCC archives. I use the search engine from here, >>and also I'm in the process of reading through the old archives systematically >>using the offline reader (I'm in the fall of 2001 currently, I think). Anyway, >>sometimes I run across a nugget that makes me just stop and go "whoah". Here's a >>quote from one of Bob's posts, originally about hashing algorithms: >> >>>I think the key to improving a program, once it plays legally, is to develop >>>a methodology to carefully profile the code, find the hot spots, and then find >>>ways to speed up those hot spots. But all the while paying _careful_ attention >>>to the overall node counts on a wide range of test positions. A 1% speedup is >>>of no use at all if you introduce an error that happens once every billion >>>nodes. I can search that many nodes in 15 minutes. I can't stand errors that >>>frequently. I have what would probably be called a "zero-tolerance for errors" >>>in Crafty. If I make a change that should only make it faster or slower, then >>>the node counts must remain constant. If they don't I debug until I find out >why and fix it. >> >>This is a fantastic point. Maybe somewhat obvious to our more experienced >>members, but certainly words of wisdom for us newbies. So, my question is, what >>methods are you all using for profiling your code? How do you go about >>identifying and fixing your hotspots? Do you have a particular test suite you >>use, or what? Andrew > >I'm surprised Bob would say that profiling is important so soon in the >development process; perhaps there's some missing context. Profiling is, imho, >about the last thing you'd want to do. > >1. Fix bugs in movegen, using perft tests. >2. Write a very simple, bug-free eval. >3. Concentrate on move-ordering, which is crucial to making the tree small. >Develop methods for measuring the quality of your ordering, don't only look at >node counts. > >Don't spend a lot of time on arcane or new ideas until you're certain what you >have is bug-free. Especially make sure your transposition code is simple and >effective, tons of problems result from bad hashing. It is clearly simple in the case of movei because I still do not use hash tables for pruning and I believe that a lot of improvement is possible even without it because I know that movei does not know a lot of things. All the versions that compete in tournaments until today know nothing about open files,knight outposts or backward pawns. I also know that except poor evaluation movei has poor order of moves and a lot of poor implementation relative to what is possible to do. For example Movei has no special function to generate only captures and it starts qsearch by generating all moves. 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.