Stockfish 1.9 JA update available

[Don]

Stockfish 1.9 JA by the Stockfish team.

We have mainly removed evaluation stuff that proved to be almost
useless, we have now access to a better hardware facility(*) and we
are able to test with a better resolution our evaluation code so to
remove old stuff that we never dared to touch.

Is it evaluation stuff that is almost useless because it caused stockfish to be slower or simply because it is not clear if the evaluation is better even with fixed number of nodes?

In the second case it is a good idea to remove it.
In the first case I am not sure because I suspect that evaluation knowledge (that is productive assuming no price in speed) can help more at longer time control.

Extrapolating to long time controls is a difficult and tricky exercise. Regarding evaluation I have experienced that most of the cases (but not all) can be safely proved at fast TC and they will hold also at longer TC.

Anyhow to answer your question, is the first case. We never test at fixed depth because is a very artificial condition and _could_ lead to artifacts.

It appears from our own testing of Komodo that most evaluation improvements can be proved at very fast time controls or even fixed depth games. But there are some notable exceptions. I think highly dynamic things such as king safety need more depth.

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

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

[swami]

Thanks, Tord, Marco and Joona.

Best wishes,
Swami

Stockfish 1.9 JA by the Stockfish team.

Windows/Linux 64/32 Intel p.g.o compiles.

What's new:

As a starter we expect just a very small increment if any.

Although a lot of stuff has changed from 1.8, as you can see from the
diffstat below:

47 files changed, 2143 insertions(+), 2629 deletions(-)


We have mainly removed evaluation stuff that proved to be almost
useless, we have now access to a better hardware facility(*) and we
are able to test with a better resolution our evaluation code so to
remove old stuff that we never dared to touch.

Apart from that the increment is really silly at fast time controls
(as we normally test), perhaps we could have some surprises (hopefully
not bad ones) at longer TC where the new time management code by Joona
could kick in with a bit of luck.

Another change from 1.8 is that we lowered the aggressiveness of both
LMR and pruning, we will se if this will pay at longer TC, at fast TC
change is almost zero....


(*) Yes we have now access through ssh to some boxes kindly made
available by Aleks Peshkov (I don't know if he wants to be named here,
I hope yes ), this is perhaps the best thing that occurred to us
in the last months because we are now able to test each change with
5K-7K games of resolution and this really opens up new possibilities.
The first and IMHO most important asset you gain is to be able to
retest all your old code and finally detect what works from what it
seems to work, but actually does nothing. The biggest part of almost
500 lines of code reductions comes from that.

As usual a big thank you to all the people that helped us, starting
from the always very kind Jim and then to all the people that
contributed with patches and ideas also privately (they know who they
are).

Have fun
Stockfish team

Download:
http://www.multiupload.com/BUP7IBJVT0
Mirror:
http://good.net/_tUdGZzThJ

Jim.

[Graham Banks]

Thanks to the Stockfish team.

[gerold]

Thanks Jim. Thanks to the Stockfish team.
So far working good in Arena 2.01.
One question Salvo Spitaleri book that
i download from your site does not work
in Arena for me.
I will try his other longer book later to see
if it will work with SF 1.9.

Best,
Gerold.

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

[alpha123]

Woo hoo!

I might try and implement Gaviota TBs in this one, regardless of whether or not the Stockfish team thinks they help.

Peter

We have in our archives a version which works with Gaviota TBs. I think Marco just released a pointer to it in one thread. My estimate is that it should take <1h to port the changes to 1.9 and <1h to test that everything works okay (assuming person knows what he is doing). But do not expect any elo increase!

Yeah, I downloaded that. It should be a huge help. Thanks.

I'll probably also implement some of the new features of Gaviota TBs 0.3.x (on-the-fly bitbases are in this one, IIRC).

Even if there is no elo increase (though I expect one ), tablesbases are necessary for some analysis.

Peter

[zamar]

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

[peter]

[D] 2kr4/pppq1p2/2nb1n2/3p2p1/5Pb1/2PPP2r/PP1BB1NP/R2QKN1R w KQ -


27.02 0:34 -2.34++ 1...g5 2.Bxg4 (424.141.487) 12172

Hi!

Good position!
Your dia doesn't fit you fen yet, 1... g5 is already played there, before going on to look more closely at the original start position, is it pawn g7 or g6? Am not sure if it matters, just for the records