Author: Will Singleton
Date: 18:00:52 05/25/04
Go up one level in this thread
On May 25, 2004 at 20:09:57, Andrew Wagner wrote: >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? It's a good area for discussion. By way of background, a question: there are a few starter programs which seem to be debugged and simple, like gerbil and tscp. How does Trueno do against those?
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.