Author: Uri Blass
Date: 05:21:41 05/26/04
Go up one level in this thread
On May 25, 2004 at 22:05:36, Tom Likens wrote: >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. Thanks. I admit that movei has some knowledge that other programs do not have but it also does not know a lot of stuff. Uri
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.