Author: Vincent Diepeveen
Date: 15:58:22 10/09/00
Go up one level in this thread
On October 09, 2000 at 18:28:21, Vincent Diepeveen wrote:
Here the output as promised. To reach 9 ply diep needs 483961 nodes
and 11.72 seconds to finish it (PIII800).
Note that i can make that 100k less nodes by not nullmoving at
depthleft==1, but that takes care it takes longer to reach 9 ply.
Also from the mainlines you'll see that DIEP's a lot busy with
silly details instead of quickly developing.
Using in diep R=3 initially, last 6 plies or so (i forgot exact
depth) R=2. So last 3 plies it uses qsearch instead of trying
to search further.
No other forward pruning used, except if you call hashtable
transposition forward pruning. The (0) in diep's output means it's
single cpu.
00:00 3 (0) 1 0.28 Ng1-f3
00:00 5 (0) 1 0.56 e2-e4
1 22 ( 0, 21) 0.02
00:00 44 (0) 2 0.00 e2-e4 e7-e5
2 106 ( 0, 65) 0.04
00:00 259 (0) 3 0.12 e2-e4 d7-d5 e4-e5
00:00 400 (0) 3 0.19 Ng1-f3 d7-d5 e2-e3
00:00 616 (0) 3 0.33 d2-d4 e7-e6 e2-e4
3 709 ( 0, 382) 0.05
00:00 1126 (0) 4 0.00 d2-d4 d7-d5 e2-e3 e7-e6
4 1977 ( 0, 991) 0.10
00:00 2946 (0) 5 0.11 d2-d4 e7-e6 e2-e3 d7-d5 Bf1-d3
00:00 4165 (0) 5 0.13 Ng1-f3 e7-e6 e2-e3 Ng8-f6 Nf3-e5
5 5291 ( 0, 2658) 0.18
00:00 8682 (0) 6 -0.02 Ng1-f3 e7-e6 e2-e3 Ng8-f6 Nf3-e5 d7-d6
00:00 13368 (0) 6 0.00 d2-d4 d7-d5 e2-e3 e7-e6 Bf1-d3 Bf8-d6
6 22917 ( 0, 13218) 0.63
00:01 47417 (0) 7 0.09 d2-d4 e7-e6 Bc1-f4 Ng8-f6 e2-e3 Nf6-e4 Nb1-c3
7 79738 ( 0, 48045) 2.00
00:03 136731 (0) 8 0.00 d2-d4 d7-d5 Bc1-f4 Bc8-f5 e2-e3 e7-e6 Nb1-d2
Nb8-d7
8 206898 ( 0, 114805) 4.97
00:09 397402 (0) 9 0.10 d2-d4 d7-d5 Bc1-f4 e7-e6 Ng1-f3 Ng8-f6 e2-e3
Nf6-e4 Nf3-e5
9 483961 ( 0, 282870) 11.72
00:24 989608 (0) 10 -0.00 d2-d4 d7-d5 e2-e3 Bc8-f5 Ng1-e2 e7-e6 Ne2-g3
Bf5-g6 Bf1-d3 Bg6xd3 c2xd3
01:09 2624746 (0) 10 0.01 e2-e4 e7-e5 Bf1-c4 Ng8-f6 d2-d3 c7-c6 Qd1-e2
Bf8-c5 Bc1-e3 d7-d6 Be3xc5 d6xc5
10 2989062 ( 0,1899883) 78.49
03:23 7604973 (0) 11 0.06 e2-e4 e7-e6 Ng1-f3 d7-d5 e4xd5 e6xd5 d2-d4
Bc8-f5 Nf3-e5 f7-f6 Bf1-d3 Bf5xd3 Ne5xd3
04:19 9782358 (0) 11 0.10 d2-d4 e7-e6 Bc1-f4 b7-b6 Ng1-f3 Bc8-b7 e2-e3
Ng8-f6 Nf3-e5 Nf6-e4 Bf1-c4
11 10033027 ( 0,6406565) 265.58
A good evaluation is big work. Especially better king safety saves hell
of a lot of nodes.
>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.