New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use only nnue evaluation #3173
Comments
nodchip/master has a 3 state Use NNUE already with options "true", "false", "pure"; so doing this would not be hard |
It seems that pure NNUE evaluations finds quickly solutions on bad positions. In some positions, standard SF (with hybrid eval) cannot find the best move to get out of losing positions because the imbalance is so important that it uses only standard evaluation and not NNUE eval any more. And if you "force" CFish for exemple, with "pure" NNUE UCI option to use only NNUE eval, it finds all the best moves in a second. May be SF should not switch to standard evaluation unless the imbalance between player and opponent is strickly positive and not absolute positive (eval > threshold and not abs(eval) > threshold). This should make SF use more often Pure NNUE eval when in negative imbalance so that it would find quickly a way out of losing positions. A try should be done in SF testing framework. Here are some exemples : |
Thanks for trying |
This has come up a number of times, and there I still see no new arguments to do 'pure' nnue, it is weaker than what we do so far. There are various parts of the engine that could be disabled to make it weaker in general, but maybe stronger for specific positions. |
Given the same reasoning it makes no sense to have pure classic either. Yet we do. How do we reconcile this inconsistency? |
because there is value in retaining what is probably the best hand-crafted evaluation ever written. We do already effectively use it in our 'hybrid' use? I think it is pretty different. The best comparison is, why don't we have an option to disable TT, NMP, LMR, ... |
Disabling TT, NMP, etc. doesn't seems like a very close comparison because those simply handicap the engine w/o providing any real benefit. (This is probably why users are not asking for those but are for pure NNUE.) Having pure eval methods on the other hand can provide unique perspectives on positions. In any case I am not advocating for removing classical. I am simply pointing out that both pure NNUE and pure classical are weaker than hybrid. It therefore seems inconsistent that we support a pure version of one and not the other. |
Right now it's probably at stockfish 11 strength. I've seen many people using it as if it was the best but it's not. I think it's even harmful. |
the evaluation has been improved, but overall, because integration with search, the whole eval+search, might eventually be weaker. |
Seems that classical is getting back to shape with latest patches and it's possible that it may beat the last classical versions in the future. Therefore I think it's best to keep Though going back to the original discussion. I think one possible reason for pure NNUE that was not mentioned before is that some (even theoretical) hardware could show the pure version to have better playing performance than the hybrid version. Fishtest uses a very narrow set of mostly AVX2 workers. A test with fixed nodes / nodestime could shed more light on this. I also agree with mstembra's statement:
but not in the way of "let's remove classic" but in the way of showing that pure has it's place. Since hybrid is now the default going in any of the two possible ways should be equal. |
Also, we don't really know what is best under TCEC-like conditions. At least at first there were many reports of bad scaling of the hybrid solution. Having a pure NNUE option could lead to more data on this question. |
Is it possible to add an uci option for using only the nnue evaluation instead of the hybrid one?
The text was updated successfully, but these errors were encountered: