Author: Andrew Wagner
Date: 19:01:31 05/25/04
Go up one level in this thread
On May 25, 2004 at 21:00:52, Will Singleton wrote: >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? Trueno usually gives TSCP a run for its money, but I don't think it's managed better than a draw yet. I haven't tried it with gerbil...I can't seem to get gerbil working with winboard. I'll have to fool with that some more.
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.