Stockfish 1.9 JA update available

[mcostalba]

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...

[peter]

Considering, the g-pawn comes from 7th in one step (and probably coming from g6 as well?), the position doesn't seem as clear to me as at first glance.
The line after 1... g5 is fine and winning but maybe not as much better as the one after 1... Re8 if you continue like this:

2kr4/pppq1pp1/2nb1n2/3p4/5Pb1/2PPP2r/PP1BB1NP/R2QKN1R b KQ - 0 1

1... g5 2. fxg5 Ne5 3. Nf4 Nf3+ 4. Kf2 Bxf4 5. exf4 Nxd2 6. Qxd2 Bxe2 7. Qxe2 Nh5

The difference to Stockfish's MV after forcing 1... g5 at your posting is
7. Qxe2 instead of 7. Ng3 there, which seems worse to me.

So for example spark 0.4 (offering the 7. Qxe2 from above by itself) having seen g5 to the end of this line gone back to the start (if it is the correct one whith pawn g7), prefers 1... Re8 again yet:

2kr4/pppq1pp1/2nb1n2/3p4/5Pb1/2PPP2r/PP1BB1NP/R2QKN1R b KQ - 0 1

Analysis by spark-0.4:


1...Te8 2.d4 Kb8 3.Lxg4 Sxg4 4.De2 g5 5.fxg5 Df5 6.b4 Te6 7.a4 a5 8.b5 Se7 9.Tg1 Sxh2 10.Sxh2 Txh2 11.Kd1 Sg6 12.Ta2 Sf4
-+ (-2.06) Tiefe: 21/50 00:04:24 1256mN

So the position still is very beautiful to deal with but maybe the two best moves are not to be rated with enough difference in eval?

[zamar]

I have many time losses with 1 sec matches. That didn't happen with versions pre 1.9.

This is because the time management code has been rewritten.
Defaults should work generally well with long-, blitz- and
lightning-games, but NOT with super-fast games.

For super-fast games I'd suggest to try following changes to parameters:

Minimum Thinking Time: 20 -> 2
Emergency Base Time: 200 -> 20
Emergency Move Time: 70 -> 7

Or even:

Minimum Thinking Time: 20 -> 1
Emergency Base Time: 200 -> 10
Emergency Move Time: 70 -> 3

Hope this helps!

[Theodor]

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??

! thread : normal
2 threads : normal
4 threads : normal
8 threads : average 350 - 450 instead 6-7-8000 !????!

[Ron Langeveld]

The object doubled in size. Is there a simple explanation for this ?

[Jim Ablett]

The object doubled in size. Is there a simple explanation for this ?

Hi Ron,
Yes, I didn't compress it with an exe packer.
Some Linux users prefer to run the 64 bit Windows version with Wine and if packed it won't run.

Jim.

[zamar]

! thread : normal
2 threads : normal
4 threads : normal
8 threads : average 350 - 450 instead 6-7-8000 !????!

Did you try 5,6 or 7 threads? Where does the problem begin?

[peter]

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...

Hi Marco!

Thanks for the explanation I think (:)) to understand even as a nonprogramming user.
But as for my simplifiying vocabulary your sentence

"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."

seems to be the easiest to understand and yet the one to ask a very special question:
Would you say the less pruning and LMR, I wouldn't have expected as for the first test positions I tried, is as well true for the workaround with nullmove?
I thought Stockfish to use it more and more from 1.6 to 1.7 (which got an extra Zugzwangdetection as an update therefore?) to 1.8.
If I simply looked at the wrong test positions at first and misunderstood Zugzwang detection to be found less than with 1.7 as for 1.8 and 1.9 again, could it then be the bigger meanings of the extensions that make SF 1.9 in some zugzwangish positions find best move less quickly, especially in positions with much material on the board?
Of course as for the other half amount of test positions it's just the other way round, but could that be answered as generally speaking as it sounds as for pruning and LMR? Would you say 1.9 uses nullmove too rather less or more than 1.8 or is it just the same and what about "extensions"?

Or to ask somewhat more directly: may I hope for a summary of the many UCI options of SF?
Tord told me about the one or the other year ago (:)) here in this forum, he would have this on his to do list as for Glaurung's hp, but I shouldn't hold my breath, I answered, I wouldn't and I'm happy, I didn't.

Of course I know with a GPL licensed project like yours, when experts look at the code itself to diversify some special settings of their own, UCI isn't as important as for a simple user like me, but I guess many users like me still love to fiddle around with all these beautiful buttons.
(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.)
If I only knew a little more about their exact meanings to change them a little more systematically and would maybe even have a way to the understanding of them on level of code itself.
Thank you very much for reading this all, if you really do so and especially many thanks for the great work you do and did for computerchess with Stockfish once again

[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.

[Theodor]

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.

Sorry, it was a problem on my Skulltrail.After a new start now is all OK.
I think Paul that your 9775 is not overclocked .Why?