Stockfish 1.9 JA update available

[mcostalba]

(aggressiveness, cowardice, what special soundings are these, aren't they, single evasion extension, how I'd love to know, what they are doing.
As a matter of fact I think I do know this and that they are doin as for the one and the other position, but then I am completely wrong again, as it seems.)

No they are not extensions. Extensions are named as such in UCI parameters.

These 2 parameters weights the king safety for both colors. To make it very simple:

Aggressiveness: Higher is the value more the engine will try to attack enemy king. Too high value could lead to suicidal king attacks !

Cowardice: Higher is the value more the engine will try to defend its king. Too high value could lead to extra passive play.


What is the best is difficult to say, we believe that default values give the best balance and highest strenght, in the average case.

[NATIONAL12]

The new stockfish has a bugg. To 8 cores he works very,very slow!
Up to 4 cores the speed is normal.

works well enough on my 8 and 12 cpu machines but only to max 8 cpu.

Impossible !!
Give him a 3' game and look at the average of k/N/s : 4-500 instead
7-8000 and depth : 11-13 instead 19-22.

Sorry to hear that
Many people have reported success using 1.8 with 8 threads. SF team doesn't have 8CPU computer, so we are unable to even test this

But perhaps you could do a little experiment.

Check average kN/s value with different threads value:

1 threads: kN/s
2 threads: kN/s
...
8 threads: kN/s

At which point you start to observe problems??

in position i was looking at in one of my games i was getting 9,500 kN/s on my Skulltrail and17,000 kN/s on my 12 cpu comp despite only running on max 8 cpu.both runs were for over an hour.

[Event ", Blitz 4m+2s"]
[Site "PAULWATSON-PC"]
[Date "2010.10.03"]
[Round "1"]
[White "Deep Rybka 4 SSE42 x64"]
[Black "Stockfish 1.9 JA 64bit"]
[Result "1-0"]
[ECO "B33"]
[Annotator "0.48;0.00"]
[PlyCount "95"]
[TimeControl "240+2"]

{Intel(R) Xeon(R) CPU X5680 @ 3.33GHz 4187 MHz W=16.7 plies; 777kN/
s; 342 TBAs; Masterbook 3.0.ctg B=22.0 plies; 13,610kN/s; Masterbook 3.0.ctg}
1. e4 {B 0} c5 {B 0} 2. Nc3 {B 0} e6 {B 0} 3. Nf3 {B 0} Nc6 {B 0} 4. d4 {B 0}
cxd4 {B 0} 5. Nxd4 {B 0} Nf6 {B 0} 6. Ndb5 {B 0} d6 {B 0} 7. Bf4 {B 0} e5 {B 0}
8. Bg5 {B 0} a6 {B 0} 9. Na3 {B 0} b5 {B 0} 10. Nd5 {B 0} Qa5+ {B 0 Both last
book move} 11. Bd2 {0.48/16 6} Qd8 {0.00/22 6} 12. Bd3 {0.54/18 7} Be7 {0.48/
22 9 (Bd7)} 13. c4 {0.59/18 19 (0-0)} Nxd5 {0.60/21 13 (bxc4)} 14. exd5 {0.58/
19 14} Nd4 {0.56/23 6} 15. cxb5 {0.69/18 10 (0-0)} O-O {0.56/23 9} 16. O-O {0.
69/17 9} Bb7 {0.72/23 6 (Qd7)} 17. bxa6 {0.74/18 16 (Be3)} Bxa6 {0.64/22 7} 18.
Bc3 {0.72/20 12 (Bxa6)} Qb6 {0.60/23 6} 19. Re1 {0.74/19 12} Bh4 {0.56/24 10
(Bg5)} 20. Bxa6 {0.81/18 14} Qxa6 {0.68/23 8} 21. Nc2 {0.81/18 9 (Bxd4)} Nb5 {
0.64/21 11} 22. Bb4 {0.84/18 21} Rfb8 {0.72/21 10} 23. a4 {0.99/16 3 (a3)} Nd4
{1.01/21 7} 24. Bc3 {1.01/16 3} Nxc2 {1.01/22 19} 25. Qxc2 {1.01/16 1} Bg5 {1.
13/21 10 (Rc8)} 26. Qe2 {1.27/16 8 (a5)} Qxe2 {1.09/21 9 (Qb7)} 27. Rxe2 {1.27/
14 1} Rc8 {1.13/24 16 (f5)} 28. a5 {1.46/18 8 (Bb4)} Rc4 {1.21/20 6 (Kf8)} 29.
a6 {1.54/18 10 (Ree1)} f5 {1.21/22 7 (Kf8)} 30. Be1 {1.81/19 10 (Ree1)} Kf7 {
1.41/24 8 (Rc5)} 31. b4 {1.83/19 5} Bd8 {1.41/25 8} 32. b5 {1.97/19 8} Ke7 {1.
37/25 5 (Ke8)} 33. f4 {2.19/17 4 (Rb1)} Bb6+ {1.69/22 7} 34. Bf2 {2.19/18 2}
Bxf2+ {2.06/23 11} 35. Rxf2 {2.19/18 2} Rb4 {2.62/21 10} 36. Ra5 {2.46/17 6}
Kd7 {2.86/21 10 (exf4)} 37. fxe5 {3.27/14 2} dxe5 {3.23/20 8} 38. Rxf5 {3.39/
15 1} Kd6 {3.39/20 6 (Rb1+)} 39. a7 {3.78/17 8 (Rf7)} Kxd5 {3.63/20 7 (Rb1+)}
40. Rf7 {4.05/15 3} Rb1+ {3.55/22 4} 41. Kf2 {4.22/16 1} Rb2+ {4.36/24 16} 42.
Kf3 {4.50/16 8 (Ke3)} Rb3+ {4.44/21 4} 43. Kg4 {5.02/13 1 (Ke2)} Rb4+ {4.64/19
7 (h5+)} 44. Kh3 {6.62/12 3 (Kh5)} Rb3+ {5.21/18 4 (Kc5)} 45. g3 {7.41/13 1
(Kh4)} e4 {9.85/21 9 (Kc5)} 46. Rb7 {7.78/15 3} Rxa7 {10.46/22 6} 47. Rbxa7 {
8.17/16 2} Kc4 {11.07/24 8 (h6)} 48. Ra4+ {10.32/16 32 (Rxg7)} 1-0

[peter]

These 2 parameters weights the king safety for both colors. To make it very simple:

Aggressiveness: Higher is the value more the engine will try to attack enemy king. Too high value could lead to suicidal king attacks !

Cowardice: Higher is the value more the engine will try to defend its king. Too high value could lead to extra passive play.


What is the best is difficult to say, we believe that default values give the best balance and highest strenght, in the average case.

Thanks again, Marco!
Could I be right, that it could make search less selective, to higher as well the aggressiveness as the cowardice?
I think both values influence the amount of pruning according to the position, don't they?
Have the values of these two parameters changed from 1.8 to 1.9?
And what about overall nullmove usage in 1.9 and about the eval of "extensions"?
What, for example, is the meaning of "single evasion extension"?
Am I wrong, that the selectivity, you describe as less than in 1.8 as for pruning and LMR could be somewhat even higher as for nullmove and extensions with 1.9?

You see, I'm not as easy to be satifsfied.

Maybe a little more detailed descriptions of the UCI options at the SF FAQs would be appreciated by other users too?

One more big thank you

[mcostalba]

And what about overall nullmove usage in 1.9 and about the eval of "extensions"?
What, for example, is the meaning of "single evasion extension"?
Am I wrong, that the selectivity, you describe as less than in 1.8 as for pruning and LMR could be somewhat even higher as for nullmove and extensions with 1.9?

Null move usage is the same of 1.8, also all the extensions usage is the same.

Regarding "singular extension" try to search for it in programing sub-forum, there is plenty of material regarding this.

Maybe a little more detailed descriptions of the UCI options at the SF FAQs would be appreciated by other users too?

But Tord didn't tell you he would have this on his to do list ?

[peter]

Regarding "singular extension" try to search for it in programing sub-forum, there is plenty of material regarding this.

Maybe a little more detailed descriptions of the UCI options at the SF FAQs would be appreciated by other users too?

But Tord didn't tell you he would have this on his to do list ?

No, we talked about Glaurung then.

Sorry for trying to understand things as a chess player not really able to read code, which is the reason not to ask them at programming subforum, in the meantime I already edited my last posting not having read your answer.
I'll be confident, with what I got, I just wanted to say just this, selectivity of the search is a mystery to me again and again watching engines' output of test positions and I was just really astonished to read, 1.9 should be simply less selective.
Thanks again

[NATIONAL12]

here is another game showing SF works fine on big hardware.




[Event ", Blitz 15m+10s"]
[Site "PAULWATSON-PC"]
[Date "2010.10.03"]
[Round "1"]
[White "Deep Rybka 4 SSE42 x64"]
[Black "Stockfish 1.9 JA 64bit"]
[Result "1/2-1/2"]
[ECO "C17"]
[Annotator "0.13;0.00"]
[PlyCount "129"]
[TimeControl "900+10"]

{Intel(R) Xeon(R) CPU X5680 @ 3.33GHz 4187 MHz W=22.7 plies; 759kN/
s; 18,089 TBAs; Masterbook 3.0.ctg B=35.7 plies; 16,465kN/s; Masterbook 3.0.
ctg} 1. e4 {B 0} e6 {B 0} 2. d4 {B 0} d5 {B 0} 3. Nc3 {B 0} Bb4 {B 0} 4. e5 {
B 0} c5 {B 0} 5. Bd2 {B 0} Ne7 {B 0} 6. a3 {B 0} Bxc3 {B 0} 7. Bxc3 {B 0} Nbc6
{B 0} 8. Nf3 {B 0} cxd4 {B 0} 9. Bxd4 {B 0} Nf5 {B 0} 10. c3 {B 0} Bd7 {B 0
Both last book move} 11. Be2 {0.13/22 69} O-O {0.00/26 28 (Nfxd4)} 12. O-O {0.
07/21 71} Rc8 {-0.08/27 45 (Nfxd4)} 13. Rc1 {0.16/20 60} Ncxd4 {0.00/26 26} 14.
Nxd4 {0.16/20 57} Nxd4 {0.00/28 41 (Qb6)} 15. Qxd4 {0.22/22 47} a6 {0.00/28 27}
16. a4 {0.22/21 53 (Bd3)} Qe7 {-0.08/25 33 (Qc7)} 17. Ra1 {0.24/20 93} f6 {0.
00/25 37 (a5)} 18. exf6 {0.28/20 86} Qxf6 {0.08/26 27} 19. Rad1 {0.26/21 44}
Qxd4 {0.08/26 77 (a5)} 20. Rxd4 {0.23/20 9} g6 {0.08/26 32 (g5)} 21. Rb4 {0.25/
20 52 (Re1)} Bc6 {0.00/29 26 (Rc7)} 22. f4 {0.24/21 64} Kf7 {0.00/29 40} 23. a5
{0.23/21 38} Ke7 {0.00/28 30} 24. g3 {0.30/21 28 (h4)} Kd6 {0.00/27 56 (Rce8)}
25. Rb6 {0.34/19 29 (h4)} h6 {-0.12/28 26} 26. h4 {0.30/19 27 (Rb4)} g5 {-0.16/
27 27 (Kc7)} 27. fxg5 {0.23/21 19} Rxf1+ {0.00/31 28} 28. Kxf1 {0.17/22 22}
hxg5 {0.00/32 25} 29. Rb4 {0.23/22 45 (h5)} gxh4 {0.00/29 27 (Rh8)} 30. gxh4 {
0.32/23 32} e5 {0.00/31 39} 31. Rg4 {0.43/22 9} Ke6 {0.00/31 26} 32. h5 {0.41/
22 13 (Kf2)} Rh8 {0.00/30 42 (Kf5)} 33. Rg7 {0.42/23 27} Kf6 {0.00/30 41 (Rh6)}
34. Rc7 {0.47/22 25 (Rg6+)} Ke6 {0.00/31 36} 35. Ke1 {0.47/24 12 (Rg7)} d4 {0.
20/29 42 (Rh6)} 36. cxd4 {0.48/24 31 (Kd2)} exd4 {0.00/28 26} 37. Kd2 {0.48/24
75 (Rg7)} Kf6 {0.12/30 28 (Rh6)} 38. b4 {0.52/24 23} Ke5 {0.24/34 91 (Ke6)} 39.
Rg7 {0.52/23 23} Kf6 {0.24/30 24 (Kf4)} 40. Rg6+ {0.52/23 19 (Rg1)} Kf5 {0.32/
33 77} 41. Bd3+ {0.51/23 19 (Rg3)} Be4 {0.00/39 16} 42. Bxe4+ {0.51/24 8} Kxe4
{0.00/34 1} 43. Rg4+ {0.51/24 10 (h6)} Kf3 {0.00/44 18} 44. Rh4 {0.51/24 11}
Kg3 {0.00/45 25} 45. Rxd4 {0.51/24 8} Rxh5 {0.00/43 24} 46. Rd6 {0.51/24 12
(Rd7)} Rg5 {0.00/40 16 (Rb5)} 47. Rb6 {0.52/23 27 (Kd3)} Rg7 {0.00/40 23} 48.
Rf6 {0.52/23 13 (Ke3)} Rg5 {0.00/40 16 (Kg4)} 49. Kc3 {0.52/24 16 (Kd3)} Kg2 {
0.00/43 16 (Rh5)} 50. Kd4 {0.52/22 22} Rg4+ {0.00/47 13} 51. Kc5 {0.52/23 8}
Rg5+ {0.00/47 16} 52. Kc4 {0.52/23 4 (Kd6)} Rg4+ {0.00/45 14} 53. Kb3 {0.51/23
4 (Kc3)} Rg3+ {0.00/45 20} 54. Kc2 {0.51/23 13 (Kc4)} Rg4 {0.00/46 13 (Rg7)}
55. Rb6 {0.51/24 8 (Kb3)} Rg7 {0.00/42 13} 56. Kc3 {0.51/24 17 (Kd3)} Kf3 {0.
00/41 19} 57. Re6 {0.51/24 4 (Kd4)} Rg5 {0.00/44 15} 58. Kd3 {0.51/25 16 (Re7)}
Rd5+ {0.00/48 13} 59. Kc4 {0.51/26 5} Rf5 {0.00/43 12 (Rb5)} 60. Kd4 {0.45/23
28 (Re7)} Rf4+ {0.00/47 14} 61. Kc5 {0.45/26 22} Rf5+ {0.00/48 14} 62. Kc4 {0.
45/26 6} Rf4+ {0.00/53 13} 63. Kc3 {0.45/26 21 (Kc5)} Rf5 {0.00/47 12} 64. Re7
{0.36/25 17 (Rd6)} Rb5 {0.00/51 12} 65. Rh7 {0.36/25 8 (Rd7) adjud. Draw
accepted} 1/2-1/2

[kgburcham]

thanks Peter
this is the corrected posiiton.


[D] 2kr4/pppq1pp1/2nb1n2/3p4/5Pb1/2PPP2r/PP1BB1NP/R2QKN1R b KQ -

Rybka 3
slow hardware

11.01 0:01 -1.26 1...Re8 2.Ng3 Bxe2 3.Qxe2 g5 (355.517) 217
12.01 0:02 -1.15 1...Re8 2.Ng3 Bxe2 3.Qxe2 g5 4.e4 dxe4 5.Nxe4 Nxe4 6.dxe4 f5 7.O-O-O Rxe4 8.Qf2 g4 9.Rde1 (486.136) 226
13.01 0:03 -1.35++ 1...Re8 (847.298) 237
13.01 0:04 -1.22 1...Re8 2.Ng3 Bxe2 3.Qxe2 g5 4.e4 dxe4 5.dxe4 Rxg3 6.hxg3 Nxe4 7.O-O-O Nxg3 8.Qc4 Nxh1 9.Rxh1 g4 10.Rh7 Nd8 11.Rg7 Bf8 12.Rg5 f6 13.Rg6 f5 (978.902) 237
14.01 0:10 -1.40 1...Re8 2.Ng3 g5 3.e4 dxe4 4.dxe4 Reh8 5.Nf1 Bxe2 6.Qxe2 Nxe4 7.O-O-O Nxd2 8.Qxd2 Bxf4 9.Nxf4 Qxd2+ 10.Rxd2 gxf4 11.Rg1 Ne5 12.Rd1 Re8 13.Rg7 (2.414.432) 246
15.01 0:13 -1.39 1...Re8 2.Bxg4 Nxg4 3.Qe2 (3.238.106) 241
16.01 0:41 -1.39 1...Re8 2.Bxg4 Nxg4 3.Qe2 g5 4.fxg5 Qf5 5.e4 dxe4 6.d4 Qf3 7.Nge3 Nxh2 8.Ng2 Reh8 9.Kd1 Na5 10.Qxf3 Nxf3 11.Rxh3 Rxh3 12.b3 Rh1 13.Ke2 (9.570.291) 235
17.01 2:12 -1.59++ 1...Re8 (32.007.512) 246
17.01 3:19 -1.64 1...Re8 2.d4 Kb8 3.Bxg4 Nxg4 4.Qe2 g5 5.fxg5 Qf5 (48.550.341) 248
18.01 3:34 -1.64 1...Re8 2.d4 Kb8 3.Bxg4 Nxg4 4.Qe2 g5 5.fxg5 Qf5 (52.041.668) 247
19.01 4:06 -1.60 1...Re8 2.d4 Kb8 3.Bxg4 Nxg4 4.Qe2 g5 5.fxg5 Qf5 6.b4 Nd8 7.a4 Ne6 8.e4 dxe4 9.Nge3 Nxe3 10.Nxe3 Qxg5 11.O-O-O Nf4 12.Qc4 Qh5 13.Kb1 Rh8 14.Rdf1 a6 (58.933.735) 244
20.01 5:17 -1.60 1...Re8 2.d4 Kb8 3.Bxg4 Nxg4 4.Qe2 g5 5.fxg5 Qf5 6.b4 Nd8 7.a4 Ne6 8.e4 dxe4 9.Nge3 Nxe3 10.Nxe3 Qxg5 11.O-O-O Nf4 12.Qc4 Qh5 13.Kb1 Rh8 14.Rdf1 a6 (75.114.024) 242
20.15 7:43 -1.80++ 1...g5 (116.832.018) 258
20.01 9:18 -2.00++ 1...g5 (145.915.761) 267
20.01 14:03 -2.40++ 1...g5 (232.105.723) 281
20.01 31:26 -2.54 1...g5 2.d4 gxf4 3.exf4 Re8 4.Be3 Na5 5.b3 Kb8 6.Ng3 Qe6 7.Nf1 Nc6 8.Rg1 Bxe2 9.Qxe2 Ne4 10.Rc1 Nxc3 11.Rxc3 Nxd4 12.Qd3 Nf3+ 13.Kf2 Bb4 14.f5 Qe5 (527.046.273) 286
21.01 52:06 -2.74++ 1...g5 (876.208.153) 286
21.01 78:16 -2.94++ 1...g5 (1.350.501.552) 294
21.01 130:14 -2.99 1...g5 2.Rg1 Bxe2 (2.279.936.025) 298
22.01 154:51 -3.00 1...g5 2.Rg1 Bxe2 3.Qxe2 gxf4 4.Nxf4 Bxf4 5.O-O-O Re8 6.Kb1 a6 7.Qf2 Be5 8.Qe2 Kb8 9.Rg2 Bd6 10.Be1 Qe6 11.Rc1 Nh5 12.Rg5 Nf4 13.Qc2 (2.731.105.856) 300
23.01 198:48 -2.97 1...g5 2.Rg1 Bxe2 3.Qxe2 gxf4 4.Nxf4 Bxf4 5.O-O-O Re8 6.Kb1 a6 7.Qf2 Be5 8.Qe2 Kb8 9.Rg2 Qe6 10.Rc1 Bf4 (3.534.191.150) 303
best move: g7-g5 time: 363:50.515 min n/s: 301.171 nodes: 6.420.629.094

[Don]

You removed knowledge from eval and also lowered search selectivity. Is there a relation between these two changes? In other words, was it neccessary(in terms of playing strength) to lower search selectivity after the removal of eval knowledge or vice versa?

No there is no connection. Eval knowledge removal is simply following the rule of simplicity: "If otherwise equal, choose the simplest version".

The selectivity is following the rule: "If otherwise equal, choose the version with least selectivity". The reasoning behind this is the observation that increasing selectivity favours short time controls. If short time controls are equal, there is a risk that increased selectivity hurts at longer time controls.

Do you have any solid evidence of the second rule about selectivity? To me this is still a question I don't have a firm answer for.

My "hunch" is that you want to be as selective as you can get away with and it will scale better - but I have not proved that conclusively.

I think LMR is big today because it probably was not clearly superior in the old days when computers were slow. In computer GO, a similar thing with Monte Carlo Tree Search - it was just not feasible when computers were slow.

We do not have evidence, an indirect test is 1.9 itself because apart from what described very little has changed.

Your guess on why LMR was useful only recently is very possible. On the other hand, SF 1.8 has probably one of the most aggressive LMR/ pruning setup, it seems even more then Rybka 4 (there are more then the expected 3-4 plies of difference in search depth), so has a sense to try to scale it down a bit, but LMR and pruning require a test coverage that is not possible to properly get for a single team: you need to test against many engines at very different TC, and this is suitable only for the public rating lists.

The bottom line is to understand if it is better to go for the extra ply at depth 20 or to find the extra tactic say at depth 16.

In the old days the compromise could have been to go for an extra ply at depth 14 or to find an extra tactic move at depth 8 and in _this_ case the result could have been that the extra tactic was better. But with increasing average search depth the balance could be different today. I have read something about diminishing return of search depth somewhere...

I think it's very important to know the answer to this as it would point to future directions for us all. It seems like one of the improvements of Rybka 3 over previous versions was that they were somewhat less selective but I'm not sure I am remembering this correctly. In my own testing it seems like every version that is a little safer plays worse at longer time controls but I have never tried to measure this with low enough error margins. As you point out this requires a LOT of CPU power to do well.

With some patience I could probably get the answer given a few weeks time. I'm just not sure I can afford to invest the CPU time to answer this one question.

I could do this with Komodo, as there is a range of settings for LMR that seem to work well, some are more conservative than others.

[Don]

Maybe we could talk Bob Hyatt into running this test for us, to determine the scalability of sf1.8 vs sf1.9 at various time controls?

You removed knowledge from eval and also lowered search selectivity. Is there a relation between these two changes? In other words, was it neccessary(in terms of playing strength) to lower search selectivity after the removal of eval knowledge or vice versa?

No there is no connection. Eval knowledge removal is simply following the rule of simplicity: "If otherwise equal, choose the simplest version".

The selectivity is following the rule: "If otherwise equal, choose the version with least selectivity". The reasoning behind this is the observation that increasing selectivity favours short time controls. If short time controls are equal, there is a risk that increased selectivity hurts at longer time controls.

Do you have any solid evidence of the second rule about selectivity? To me this is still a question I don't have a firm answer for.

My "hunch" is that you want to be as selective as you can get away with and it will scale better - but I have not proved that conclusively.

I think LMR is big today because it probably was not clearly superior in the old days when computers were slow. In computer GO, a similar thing with Monte Carlo Tree Search - it was just not feasible when computers were slow.

We do not have evidence, an indirect test is 1.9 itself because apart from what described very little has changed.

Your guess on why LMR was useful only recently is very possible. On the other hand, SF 1.8 has probably one of the most aggressive LMR/ pruning setup, it seems even more then Rybka 4 (there are more then the expected 3-4 plies of difference in search depth), so has a sense to try to scale it down a bit, but LMR and pruning require a test coverage that is not possible to properly get for a single team: you need to test against many engines at very different TC, and this is suitable only for the public rating lists.

The bottom line is to understand if it is better to go for the extra ply at depth 20 or to find the extra tactic say at depth 16.

In the old days the compromise could have been to go for an extra ply at depth 14 or to find an extra tactic move at depth 8 and in _this_ case the result could have been that the extra tactic was better. But with increasing average search depth the balance could be different today. I have read something about diminishing return of search depth somewhere...

I think it's very important to know the answer to this as it would point to future directions for us all. It seems like one of the improvements of Rybka 3 over previous versions was that they were somewhat less selective but I'm not sure I am remembering this correctly. In my own testing it seems like every version that is a little safer plays worse at longer time controls but I have never tried to measure this with low enough error margins. As you point out this requires a LOT of CPU power to do well.

With some patience I could probably get the answer given a few weeks time. I'm just not sure I can afford to invest the CPU time to answer this one question.

I could do this with Komodo, as there is a range of settings for LMR that seem to work well, some are more conservative than others.

[PauloSoare]

Thanks to Tord, Marco and Jooana for a new Stockfish version !
Thanks to Jim Ablet too.
Even if the version does not have significant improvements,
it's nice to test in test suites. Jouni was the first.
Good luck.
Paulo Soares