Author: Dann Corbit
Date: 19:41:08 06/15/04
Go up one level in this thread
On June 15, 2004 at 20:21:01, Andrew Wagner wrote: >On June 15, 2004 at 20:09:48, Dann Corbit wrote: > >>On June 15, 2004 at 19:28:36, Andrew Wagner wrote: >> >>>I've heard it said before that it's not good to compare node counts between >>>engines, and that node counts aren't a good indication of strength. So, I've >>>been staying away from that a lot. >>> >>>The other day, I was chatting with my good friend Jaime Benito de Valle Ruiz. We >>>see each other a lot on ICC and compare notes on our engines. We decided to play >>>a fixed-depth game between our engines, to test eval strength. In the process of >>>the game, he noticed that my node count was ridiculously higher than his. For >>>example, in one position, where I was getting 277k nodes, he was getting like >>>11k. Other engines varied, but no more than about 50k nodes. >>> >>>So we started doing some tests. For him, he got a huge node reduction by using >>>some sophisticated aspiration windows. So, my question is three-fold: >>> >>>1.) Do most engines get a similarly large reduction in nodes by using aspiration >>>windows? >> >>It will depend on what other things you are using to trim the tree. >> >>>2.) What other techniques reduce node counts at a fixed depth? >> >>A. Move ordering is the most important thing. So a good hash table is a must. nodes ==> sqrt(nodes) for worst case to best case. Your actual benefit will be smaller >>B. After that, null move reduction will be a stupendous node reducer. nodes/2 >>C. PVS search does fewer nodes than ordinary Alpha-Beta nodes *2/3 >>D. SEE is worth a lot for reduction nodes *2/3 >>E. Razoring will reduce nodes, but you have to be careful not to shave the skin >>off with the hair Anything you want, but it better be smart. >>F. IID will help, especially in deep searches Small reduction that gains more with more depth. If your move ordering is already excellent, the gain will not be as dramatic. >>G. Aspiration window (mentioned above) reduces nodes. nodes *0.9 >>H. Easy move cutoff Depends on where you set it. Adds a big danger factor if you give up too easily >>Here are things that will cost you nodes, but are a good idea anyway: >>A. Check extensions Adds quiescent nodes, but still nodes. >>B. Increasing quiescense depth (if you don't allow infinite quiescence) Big slowdown for active positions, but prevents dumb moves >>C. Single reply extensions Like B, but when lots of forced moves are present rather than captures (and whatever else you quiesce) >>D. Pawn race extensions Adds nodes when pawns are on open files >>E. Recapture extensions Another safety valve >>Also, adding king safety and pawn structure to your evaluation will slow down >>the NPS greatly, but make the program play better. >> >> >> >>>3.) To what extent are node counts reliable for determining engine strength? >> >>Not generally useful, except to compare against yourself. Goliath will be >>around one million NPS on a machine where Yace will get 300K NPS. But they are >>about the same strength. > > >I should have been clearer. I didn't mean NPS, but number of nodes searched. So did I, for the most part.
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.