Rodent needs a test

[PK]

I am developing Rodent on a laptop - a decent one as far as laptops go, but obviously limited in terms of number of cores and hash size. For that reason not all tests that I'd like to make are feasible, and sometimes I am moving in the dark.

As of now, I need a confirmation that increasing hash size beyond 4096 MB is viable. If anyone can run the latest Rodent (https://ci.appveyor.com/project/nescitu ... /artifacts) on a 64-bit machine capable of supplying 8192 MB or 16384 MB of hash, I'd like to know the following:

1) (easy) does increasing hash size beyond 4096 MB cause a slowdown?
2) (harder) on 4 to 8 threads, does increasing hash size beyond that improve playing strength?

[voffka]

Hello Pawel,

I can run Rodent on 128 Gb of hash and on 21 CPU if needed. I don't know if Rodent supports this configuration. Igel does

[PK]

If there's not much slowdown with a bigger hash, then I'd be grateful. Rodent will default to its max hash (as displayed in UCI options), but it will handle 21 threads all right.

[Dann Corbit]

If there's not much slowdown with a bigger hash, then I'd be grateful. Rodent will default to its max hash (as displayed in UCI options), but it will handle 21 threads all right.

Something peculiar. I told it to use 16GB and it used 27GB instead.

This is probably pertinent

ramhog.png

:

2019-05-09 16:09:20.621-->1:setoption name Hash value 16384
2019-05-09 16:09:20.626-->1:setoption name Threads value 11
2019-05-09 16:09:20.631-->1:setoption name PersonalityFile value
2019-05-09 16:09:20.636-->1:setoption name UseBook value false
2019-05-09 16:09:20.642<--1:info string ttsize 1073741824ll

[tpoppins]

Results from startposition, at 40/40

1 thread

Code: Select all

16 GB
d=22, 31s, 943 kN/s

8 GB
d=22, 31s, 931 kN/s

4 GB
d=23, 31s, 977 kN/s

1 GB
d=23, 31s, 998 kN/s

8 threads

Code: Select all

16 GB
d=25, 31s, 6255 kN/s

8 GB
d=23, 31s, 6352 kN/s

4 GB
d=26, 31s, 6360 kN/s

1 GB
d=25, 31s, 6492 kN/s

I can confirm Dann's observations of memory usage irregularities. With one thread it tends to exceed the expected usage by about 2GB. With eight threads it is already 3X what it's supposed to be with the 4GB hash, and about 27GB when a 16GB hash is set. That's going by the Working Set and Commit Size columns of Task Manager.

[Werner]

Hi,
do you have plans for an official release (when?)
...and did you find the reason with the hash issue?

2019-05-19 11:00:11,247<--1:info string ttsize 65536ll ???
2019-05-19 11:00:11,249-->1:isready
2019-05-19 11:00:11,286<--1:readyok

[PK]

Issue has been solved - it was an embarassing mistake of initializing huge arrays for Texel tuning in each engine instance

As for official release, I will probably wait for the next Graham's tournament.