thank you

[samer707]

HELLO , i found something important to mention , the ( Author: Joost VandeVondele
Date: Thu Aug 20 21:13:07 2020 +0200
Timestamp: 1597950787) is working good for chesspartner software , but the ( Author: Joost VandeVondele
Date: Thu Aug 20 21:14:32 2020 +0200
Timestamp: 1597950872 ) not continue after 2 moves and stops analyse , video is here about that , and all developer versions after that the same till now 23/8/2020

[Hanamuke]

I assume the first two moves are book moves and did not require the engine.
For the latests version you need to either disable NNUE in the UCI options of the engine (it's enabled by default since this patch) or download the default net, and put it next to your downloaded binary. The link for the default net is right below the download link for the binary.

[samer707]

thank you

[vondele]

closing as resolved.

[samer707]

hello , is the (default net nnue) give the same development build action and moves when i download it and put it beside development build whatever version of development build ?

[vondele]

each development build comes with one specific default net, which is indicated by the default value of EvalFile. That's the net to use. The net doesn't change often, so if the name is the same, you don't need to download again.

[samer707]

thank you

[samer707]

did you see the comment with video i sent it before 23 hour before ? because the new development build until now dose not work without putting (default net nnue) beside it, and all versions before working only good

[samer707]

sorry : all versions before working lonely , good

[vondele]

yes, things are changing, and we're figuring out the best way to deal with the addition on the net. On the positive side, enjoy a 100+ Elo stronger chess.

[samer707]

thank you , yes my only best engine in the world is stockfish , because of That i want it to develop ahead without little changes that affects on It's work

[samer707]

it is strongest chess engine for me , i depend on it to solve chess positions

[samer707]

Thanks for the interest, ( for last development versions ) , it is possible that you integrate (nn-82215d0fd0df.nnue) with Developer, i do not know , but this is very good act ,however, I was confident of your interest because Stockfish is a company that respect its self and its customers

[samer707]

the same problem in same developer person that i mentioned before in video ( samer707 commented on May 19 ) the developer is (Author: Sami Kiminki)
and the problem in (Author: Sami Kiminki
Date: Mon Sep 21 08:43:48 2020 +0200
Timestamp: 1600670628Date: Mon Sep 21 08:43:48 2020 +0200
Timestamp: 1600670628) repeated again the same error that i mentioned in video ( samer707 commented on May 19 ) , (this is for because i respect stockfish company)

[vondele]

I'll reopen this issue, but it is unclear what exactly the issue is.

[vondele]

@skiminki I actually have an idea. With 485d517 to use large pages for the nets, we again have the output
info string Hash table allocation: Windows large pages not used.
before any uci command which breaks certain GUIs. Also, this output is now somewhat wrong, as it appears on the allocation of the net variable. Could you have a look how this could be fixed?

[samer707]

ok the problem i will explain again but by video , the problem is when i import engine ((Author: Sami Kiminki
Date: Mon Sep 21 08:43:48 2020 +0200
Timestamp: 1600670628Date: Mon Sep 21 08:43:48 2020 +0200
Timestamp: 1600670628) that make chesspartner program freeze and stop

[samer707]

but the versions before working good , the same problem happened before from the same developer and you fixed it , but problem returned again by this developer, (you can watch story of my chat) , remember i am not programmer to fix this , i want new version that fix this

[samer707]

ok the video is here notice that Stefan Geschwentner - Timestamp: 1600669150 is working
but Sami Kiminki - Timestamp: 1600670628 is not working in chesspartner and make it freeze , thank you at all

[skiminki]

With 485d517 to use large pages for the nets, we again have the output

Sounds like a likely culprit.

Could you have a look how this could be fixed?

The quick'n'dirty fix would be to suppress 2 first prints, instead of just one, and reformulate the info print a bit. However, this setup will remain as fragile as it is today.

For long-term, better fixes would be to do either or both:

(1) Deferred resource allocation on 'isready' or on the first 'go' command. Something similar to this one: skiminki@607988f

IIRC, the idea was rejected last time for the fear of timeout on 'go' if GUI/arena software is missing the 'isready' command. However, I only later realized that the timeout will happen even if resources are allocated on "setoption". Consider:

• setoption name Hash value 32768
• go wtime 1

The hash is still being resized when "go wtime 1" is sent. Timeout. That's why "isready" --> "readyok" synchronization is critical so that the GUI/arena knows when the engine is ready for the prime time.

Deferred allocations would also push the info strings to "isready", which is after "uci" by the protocol definition. There are also other benefits with deferred allocs, namely, faster engine init in case the GUI sends "Hash" before "Threads"

(2) Instead of printing out the use of large pages at alloc, maybe we could print them on "isready" as a summary. Something like:

> isready
< info Windows: large page memory not used
< readyok

> isready
< info Windows: large page memory used
< readyok

> isready
< info Windows: large pages used for some allocations but not for all.
< readyok

or

> isready
< info Windows: using 0 MB large page memory for requested total of 1234 MB
< readyok

> isready
< info Windows: using 1234 MB large page memory for requested total of 1234 MB
< readyok

[skiminki]

Let’s get the dirty fix in first, and worry about longterm later? The print is still correct about hash table, since the weights alloc print gets suppressed. Pushed a PR

[samer707]

thank you , Respectable company stockfish and members , the problem solved in last ( Author: SFisGOD
Date: Fri Sep 25 17:44:19 2020 +0200
Timestamp: 1601048659
thank you

[samer707]

sorry , thank you