I recently analyzed a game with the embedded stockfish 16 40MB engine (analysis tab at the end of a game) .
I would like to do a deep analysis of a certain position, and so start tuning parameters, I noticed that now the maximum memory I can assign is 64MB while few days ago it was up to 1GB (same engine).
I know that chess engine take huge benefit in big cache size, used to not re-evaluate same position again and again while iterative deepening take place, so I was puzzled by the limitation (my device currently have plenty of unused ram).
Is it that the NNUE part (I didn't know how it works) who recently changed how engine handle processing, and now huge cache is not useful anymore?
Or may it be a browser issue (that doesn't see all available memory)?
Anyway I have to admit that current setup is still quite fast, but I would like to improve it a bit
I checked now and the memory slider offers powers of 2 from 16 to 512 MB so it's probably a local issue (or temporary).
Sounds like you were previously on a desktop Chromium browser when you saw 1GB and then you were on an iPad or Android device where you saw 64MB. Or there's a bug in our browser detection code. Max hash is governed by the device/browser you're using, not the selected engine. Here's the current breakdown for max hash:
Desktop browser - 512MB
iPhone - 32MB
iPad/Android - 64MB
I did not know there was a computing power monotonic relation with visuo-spatial caliber.
Hi :)
@schlawg said in #3:
> Sounds like you were previously on a desktop Chromium browser when you saw 1GB and then you were on an iPad or Android device where you saw 64MB. Or there's a bug in our browser detection code. Max hash is governed by the device/browser you're using, not the selected engine. Here's the current breakdown for max hash:
>
> Desktop browser - 512MB
> iPhone - 32MB
> iPad/Android - 64MB
Always used the same chrome browser on the same mobile device, probably a temporary issue I think. I wil try cleaning cache and restarting
I have made few tests and I have found that from my mobile I am limited to 8core 64mb
That the stockfish 11 HCE (a new option even if a legacy engine) is super fast, and that stockfish 16 40mb become slow (in a benchmark position I was able to analyse up to 2milon-pos/s now not more that 500k).
So I think that with the new option (stockfish 11 HCE) some was changed in the settings on how you can setup engine.
On the same device I used for the tests above, if I set the browser in desktop mode, I am able to setup up to 32core and 512mb.
So seems a new platform limit rather than a my device limit.
but is there an explanation concerning the op hypotheses or subquestions about the decrease from 1G in any case?
I like to think about a chess interpretable understanding for the engine goggles point of view of which the only chewable information display we have is a mere one number, now apparently within -100.00 and +100.00 so 4 significant digits of user visible information.
And the op questions are overlapping such interest of mine. Knoweing the role of the TT table and all addition lichess caches from user local OS swamp combined with browser mini-OS space on same machine, to lichess server based ones like "the Cloud"... What was the 1G attributable to? it seems that op is linking it to the transposition table as in the command line option UCI controllable.
Has the change been of lichess caches or other ways of extra layer on top of SF behavior nature, or propagating some change in SF own caches or memory needs behavior..
just curious of behind the chess engine oracle curtain, as usual.. so I can use it more effectively as the op intends as well.
dboing, it is indeed the same as the uci hash option.
ender, that makes sense. a useragent string that looks like a mobile browser will get the reduced maximums whereas ones that looks like desktop browser gets the 512MB max
Nodes per second bears little relation to analysis quality in the age of nnue. Let each engine run for the same amount of time on the same position and SF16 40MB's analysis is generally the best, followed by SF16 7MB, SF14 NNUE, and finally SF11 HCE in a distant fourth. This holds whether you're running 96 threads on the latest threadripper or a budget android with 2 threads.
