Came across this position that crashed (ran out of memory) my lc0 build on google colab, using 26gigs ram and a Tesla v100.
[d]r1b1k1nr/pp2bppp/2n1p3/4P3/3p4/2NP1N2/P1P2PPP/R3KB1R w KQkq -
Thought maybe it was my build, but I also tried it at home using the vanilla lc0 from the official website and the 256x20-t40-1541.pb.gz NN
On my GTX 1650, after 5 ply it dropped to a crawling 10 nps and ate up all my memory. I was trying for depth 12 analysis.
Any ideas or anyone else able to reproduce this behavior?
Odd position for lc0 with 256x20-t40-1541.pb.gz NN
Moderators: hgm, Rebel, chrisw
-
- Posts: 1342
- Joined: Wed Mar 08, 2006 9:41 pm
- Location: Morgantown, WV, USA
-
- Posts: 3293
- Joined: Wed Mar 08, 2006 8:15 pm
Re: Odd position for lc0 with 256x20-t40-1541.pb.gz NN
My GTX card never reached 7 plies to output something in Fritz GUI. I use one big net.
Jouni
-
- Posts: 536
- Joined: Thu Mar 09, 2006 3:01 pm
Re: Odd position for lc0 with 256x20-t40-1541.pb.gz NN
At one time I think lc0 would simply use up all RAM storing the tree.
There are parameters to limit memory use.
--ramlimit-mb (command line) RamLimitMb (UCI setoption)
Maximum memory usage for the engine, in megabytes. The estimation is very rough, and can be off by a lot. For example, multiple visits to a terminal node counted several times, and the estimation assumes that all positions have 30 possible moves. When set to 0, no RAM limit is enforced.
Default value: 0
Minimum value: 0
Maximum value: 100000000
I'm not sure how the separate
--nncache NNCacheSize parameter interacts with the above
Number of positions to store in a memory cache. A large cache can speed up searching, but takes memory.
Default value: 200000
Minimum value: 0
Maximum value: 999999999
There are parameters to limit memory use.
--ramlimit-mb (command line) RamLimitMb (UCI setoption)
Maximum memory usage for the engine, in megabytes. The estimation is very rough, and can be off by a lot. For example, multiple visits to a terminal node counted several times, and the estimation assumes that all positions have 30 possible moves. When set to 0, no RAM limit is enforced.
Default value: 0
Minimum value: 0
Maximum value: 100000000
I'm not sure how the separate
--nncache NNCacheSize parameter interacts with the above
Number of positions to store in a memory cache. A large cache can speed up searching, but takes memory.
Default value: 200000
Minimum value: 0
Maximum value: 999999999
-
- Posts: 1342
- Joined: Wed Mar 08, 2006 9:41 pm
- Location: Morgantown, WV, USA
Re: Odd position for lc0 with 256x20-t40-1541.pb.gz NN
Thank you very much, I'll check the info dump at the beginning of uci to see what other memory options are available. Even when going down to 8-9 ply its odd how some positions can be evaluated in a matter of seconds, and others with the same piece count can take 15+ minutes and consume a lot of ram.
-
- Posts: 536
- Joined: Thu Mar 09, 2006 3:01 pm
Re: Odd position for lc0 with 256x20-t40-1541.pb.gz NN
Keep in mind that "depth" with Lc0 is nothing like A/B engines.
It is an estimate based on nodes.
It is an estimate based on nodes.
-
- Posts: 1342
- Joined: Wed Mar 08, 2006 9:41 pm
- Location: Morgantown, WV, USA
Re: Odd position for lc0 with 256x20-t40-1541.pb.gz NN
Aye noticed that when I started testing lc0 in Chessbase against Fritz 17. lc0 would hit 10-12 depth while Fritz was pushing 30.
Off topic, but wonder how Chessbase is going to handle that in regards to donating engines to their "Let's Check" system. It ranks and displays top 3 evals by depth. I stopped donating lc0 even if stronger, because I was never hitting the depth to get listed.