Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Initial Position Search Nodes

Author: Vincent Diepeveen

Date: 15:28:21 10/09/00

Go up one level in this thread


On October 09, 2000 at 06:09:53, Steve Maughan wrote:

>Having managed to add all the normal stuff to my chess program (hash, SEE
>sorting, null move, killers, internal iterative deepening etc) I am a little
>disappointed with the depths it is reaching.  At first I thought it must be poor
>move ordering but I've checked that and it seems OK (I do Hash Move, Good
>Captures, Killer1, Killer2, History, Bad Captures).  I decided to see how long
>it took to complete it's nineth ply search from the initial position.  Here are
>the results along with those of other programs (450 MHz P2):

I'm not so sure you can say that you're ok or doing bad.

Openingsposition is a big big exception. suppose that you get huge
score for center pawns and knights on f3.

Try it simply. Try for a small test to increase the bonus for a knight on
f3 by 0.2 pawn, a pawn on d4 with 0.2 pawn idem for black.

Now rerun the test and how many nodes do you need then?

I bet millions less.

In fact i'm pretty sure that this can convince you that openingsposition
isn't a very good test to do.

A big initial trick for move ordering is to generate king moves as last moves,
but castling if possible as first.

As soon as the boundschecker is a bit finished under linux
i'll produce some DIEP outputs. Note that this is with adaptive
double nullmove.
So first few plies R=3 then R=2, but for initial position that doesn't
matter too many nodes.

>MyProgram 31 secs 6,486,200 nodes
>Ikarus 15 secs 888,000 nodes
>HIARCS 18 secs 677,000 nodes
>Faile 50 secs 3,500,000 nodes
>Crafty 17.11 8 secs 800,000 nodes
>Goliath Light 0 secs 31,000!!!!
>Nimzo 7.32 13 secs 3,260,000
>
>A couple of points.  Firstly, how on earth can Goliath search 9 ply so quickly
>and using so few nodes?  I can't beleive that Goliath is the most selective.

big scores for a few pawn moves and knights and you are at iteration 20
before you know it. In case of goliath i'm quite sure it's pruning
a lot last n plies. Also it's a very fast program (?).

>Secondly, it would seem that Ikarus' nodes / sec are much lower than indicated
>when calculated using nodes visited divided by time!

>Finally, for my program what am I doing wrong?  Am I missing something?  What
>other forms of selectivity are coming into play here?  I'm just doing a vanilla
>Alpha / Beta but it's taking me ages (6 million nodes) to complete 9 ply.
>Perhaps Bob could shed some light on Crafty's impressive 8 secs and only 800 kn.

I bet he's gonna mention he's not doing checks in qsearch, but you
didn't see DIEP output yet, note that diep's not optimized for openings
position. I get it out of book always in 0 nodes searched :)

> Could it be my poor evaluation funtion which is only a primitive piece-square
>table?
>
>All help appreciated!
>
>Regards,
>
>Steve Maughan



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.