TalkChess.com

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

// We use NO_PIECE_TYPE as a place holder for the bishop pair "extended piece",
// this allow us to be more flexible in defining bishop pair bonuses.
for (pt1 = PIECE_TYPE_NONE; pt1 <= QUEEN; pt1++)

Ralph Stoesser wrote:Thanks for the new version!

material.cpp, line 336

// We use NO_PIECE_TYPE as a place holder for the bishop pair "extended piece",
// this allow us to be more flexible in defining bishop pair bonuses.
for (pt1 = PIECE_TYPE_NONE; pt1 <= QUEEN; pt1++)

"NO_PIECE_TYPE" within comment has been overlooked by your search&replace tool.

Jim Ablett wrote:
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.

Uri Blass wrote:

Jim Ablett wrote:
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.

mcostalba wrote:

Uri Blass wrote:

Jim Ablett wrote:
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.

Uri Blass wrote: I understand it but the question is if removing the evaluation knowledge has a significant effect on the speed of stockfish in nodes per second(not 1% but 10% or 20%).