Author: Tom Likens
Date: 19:05:36 05/25/04
Go up one level in this thread
On May 25, 2004 at 20:36:47, Uri Blass 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. >> >>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 Uri, If I didn't know better from the above description I would assume movei was a random move generator and not much more. And yet, it keeps winning and winning! Perhaps we should hold a contest to determine who is the most self-effacing programmer you, Tord or Matthew (of BigLion fame) ;-) regards, --tom P.S. By the way, congrats on your showing in WBEC.
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.