Author: Rick Hagen
Date: 04:38:05 10/27/05
Go up one level in this thread
On October 26, 2005 at 16:13:00, Gerd Isenberg wrote: >On October 26, 2005 at 07:01:10, Rick Hagen wrote: [...] >>First number is from the starting postition, second from 8-pawn position: >> >> KN/s >>Junior 9 1460 1415 >>Hiarcs 9 218 430 >>Shredder 9 365 620 >>CT 15 435 580 >>Toga II 1.0 760 1355 >>Fritz 7 1000 645 >>Fritz 9 930 540 >>Crafty 19.15 865 855 >>Pro Deo 1.1 735 1100 >> >>P4(.) 3Ghz >>HT 128 MB >>TBs off (Not installed atm...) >> >>So, my question: who are the "odd" ones out, and why? >> > >A few aspects on your interesting nps-compare: Hi Gerd, Thanks for calling it intersting; remember I'm not a chess-programmer so have patience with me, I might loose track somewhere.. > >The ratio of the number of expensive nodes versus cheap nodes during a search >and the (average) ratio of the implementation depending duration of expensive >nodes (full eval, all-nodes) versus cheap nodes (repetition detection, lazy eval >cuts at leaves, etc.) might be the main factor to explain the nps behaviour. Okay, so far so good (only minor headache now..) > >The ratio of expensive nodes versus cheap nodes is depending on the position and >of course on the implementation of the engine. If we use forward pruning to cut >futile subtrees, we have relative more expensive nodes. If we, probably >depending on the state of the game, don't use futility pruning (but probably >lazy eval), we will have relative more cheap nodes. > >More hashhits, better move-ordering favours expensive nodes and therefor lower >nps. Also some extension (and reduction) effects may cause the engine to have >more cheap or lazy eval-cuts at the leaves. > >There are a lot of other things of course, pawn-hashing, eval-hashing, >move-generation, incremental verus on the fly attack or move-generation, legal >versus pseudolegal movegen and whatever else... > >Movegen and attack generation is usually faster in endings with no sliding >pieces also due to less pieces to generate moves for. > >More sophisticated search statistics would be interesting. >Eg. about the number of fullsearch-, [pre[pre]...]-frontier-, horizon- and >qsearch-nodes, differentiated by foreward cuts (hashhit-cuts, nullmove-cuts, >(lazy)eval-cuts, etc.) and beta cuts and beta cuts after first move. Well Gerd, that seems a very comprehensive explanation to this "mystery". You've just wrote a Hitchhikers Guide to Chess Programming for me. Somehow you've got me persuaded to read articles on chess-programming, just to understand what makes them tick. (and to comprehend what you're trying to explain to me.) Running this tournament it seems that there are more ways to Rome, concerning this type of position, or any pawn-endgame for that matter. How does Isichess 2.5 compare to the engines listed? And is this kind of position (including running a tournament) of any relevance to a chess-programmer at all? Thanks again for your time. Really appreciate it. Cheers, Rick > >Gerd
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.