Author: Robert Hyatt
Date: 18:27:59 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. I was talking about when you reach the point of trying to make things go faster. IE you add an incremental update of something. If it isn't supposed to change the move ordering, or the evaluation, or the search extensions, it had better _not_ change the node counts... > >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. > >Once you have a good, stable platform to build on, you can be sure that your >future experimentation will be productive.
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.