Two suggestions for Stockfish

[sje]

Symbolic runs in two modes of selfishness: if it is running on the same machine as another chess program (including a copy of itself), then it allocates tables to use less than 40% of memory. If it is running in greedy mode then it tries to take up to 80% of memory. This does not apply to thread allocation; the program always uses all the cores available.

[mcostalba]

If you are in agreement and want to change to 1 thread I'll follow the Stockfish lead in the setting of Hash table default size. So I would change the default to 32 in future versions. Do you plan to keep it at 32 for a while?

Before it was 128MB, we have switched to 32MB recently due to issues on some mobile/not PC platforms, where the available memory is low.

But I think this is more a problem for open sources engines that can be downloaded and compiled directly by the user for any kind of platform, even for one not foreseen in advance by the authors: in this case it was a MIPS router (!), if I remember well, that crashed on startup due to too big hash size allocation.

Regarding the cpu count, the only thing that stops me to drop the cpu count code is that minimum split depth (msd) default value depends on cpu count and gets bigger with increasing detected cpu number.

For a user is more or less easy to set the correct cpu count, starting from the default 1, but instead the minimum split depth is too technical and we cannot pretend user understands what this parameter means, even less he sets the best value. OTH we cannot automatically change msd whenever cpu count changes, because we want to have the possibility to still tweak that parameter for a given cpu count. So current code chooses best msd at startup, based on cpu count, but only once, allowing user to further change both in an independent way.

[zamar]

If you are in agreement and want to change to 1 thread I'll follow the Stockfish lead in the setting of Hash table default size. So I would change the default to 32 in future versions. Do you plan to keep it at 32 for a while?

Before it was 128MB, we have switched to 32MB recently due to issues on some mobile/not PC platforms, where the available memory is low.

But I think this is more a problem for open sources engines that can be downloaded and compiled directly by the user for any kind of platform, even for one not foreseen in advance by the authors: in this case it was a MIPS router (!), if I remember well, that crashed on startup due to too big hash size allocation.

Regarding the cpu count, the only thing that stops me to drop the cpu count code is that minimum split depth (msd) default value depends on cpu count and gets bigger with increasing detected cpu number.

For a user is more or less easy to set the correct cpu count, starting from the default 1, but instead the minimum split depth is too technical and we cannot pretend user understands what this parameter means, even less he sets the best value. OTH we cannot automatically change msd whenever cpu count changes, because we want to have the possibility to still tweak that parameter for a given cpu count. So current code chooses best msd at startup, based on cpu count, but only once, allowing user to further change both in an independent way.

There are couple of ways around this...

A) Two UCI options:
- "Automatically Detect Optimum Split Depth" = (Yes/No)
- "Manual Minimum Split Depth" = (4...10)

B) Only one UCI option:

- "Mimimum Split Depth" = (Auto, 4, 5, 6, 7, 8, 9, 10)

[Joerg Oster]

If you are in agreement and want to change to 1 thread I'll follow the Stockfish lead in the setting of Hash table default size. So I would change the default to 32 in future versions. Do you plan to keep it at 32 for a while?

Before it was 128MB, we have switched to 32MB recently due to issues on some mobile/not PC platforms, where the available memory is low.

But I think this is more a problem for open sources engines that can be downloaded and compiled directly by the user for any kind of platform, even for one not foreseen in advance by the authors: in this case it was a MIPS router (!), if I remember well, that crashed on startup due to too big hash size allocation.

Regarding the cpu count, the only thing that stops me to drop the cpu count code is that minimum split depth (msd) default value depends on cpu count and gets bigger with increasing detected cpu number.

For a user is more or less easy to set the correct cpu count, starting from the default 1, but instead the minimum split depth is too technical and we cannot pretend user understands what this parameter means, even less he sets the best value. OTH we cannot automatically change msd whenever cpu count changes, because we want to have the possibility to still tweak that parameter for a given cpu count. So current code chooses best msd at startup, based on cpu count, but only once, allowing user to further change both in an independent way.

There are couple of ways around this...

A) Two UCI options:
- "Automatically Detect Optimum Split Depth" = (Yes/No)
- "Manual Minimum Split Depth" = (4...10)

B) Only one UCI option:

- "Mimimum Split Depth" = (Auto, 4, 5, 6, 7, 8, 9, 10)

I vote for B.