Author: Andrew Wagner
Date: 17:09:57 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. Here's the link, so you can read it in context, if you'd like: http://chessprogramming.org/cccsearch/ccc.php?art_id=112972 > >1. Fix bugs in movegen, using perft tests. He does say "once it plays legally". To me, that implies a bugfree movegen... >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. > I would count these as what he calls "hot spots". Especially move ordering (though good eval helps move ordering). >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. I would also be interested in a process for this. What process do you use to really be absolutely sure your program is bug free? Especially your hash table code. E.g. at the moment, I think Trueno is bug free, more or less. But I haven't found a good thorough test to give it that will tell me. > >Once you have a good, stable platform to build on, you can be sure that your >future experimentation will be productive. But what does the "build on" process consist of? That's the question. Bob's answer is this profile/find hotspots/fix-while-watching-node-counts process. But how do you implement this?
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.