use sleeping threads

[mcostalba]

How about then using the same basic wording but making it boolean:

Idle Threads Sleep = true/false

Yes, I vote for this one. "Spin" is too technical and could be not clear to not programmers, also "sleep" is technical jargon somehow, but the intuitive meaning is clear to everybody and is more or less correct.

[mcostalba]

You could for instance include a floating divide in the spinning loop..

I don't see the difference from just keeping the threads spinning.

In the "Idle Threads Sleep" case instead OS is free to reschedule another process or simply to go idle, IOW you have snappier UI and/or less fan noise. The latter is the main reason why we set it to true in the dev version: CPU is much less power hungry even with all cores used.

I'd even suggest to set "Idle Threads Sleep" to true as default for Android or anyhow where battery matters.

It is set to false for release because we have seen to lose some few ELO point vs spin case, but the lost is really small and marginal.

[zullil]

How about then using the same basic wording but making it boolean:

Idle Threads Sleep = true/false

Yes, I vote for this one. "Spin" is too technical and could be not clear to not programmers, also "sleep" is technical jargon somehow, but the intuitive meaning is clear to everybody and is more or less correct.

+1

[Don]

You could for instance include a floating divide in the spinning loop..

I don't see the difference from just keeping the threads spinning.

In the "Idle Threads Sleep" case instead OS is free to reschedule another process or simply to go idle, IOW you have snappier UI and/or less fan noise. The latter is the main reason why we set it to true in the dev version: CPU is much less power hungry even with all cores used.

I'd even suggest to set "Idle Threads Sleep" to true as default for Android or anyhow where battery matters.

It is set to false for release because we have seen to lose some few ELO point vs spin case, but the lost is really small and marginal.

My theory on this is not because it helps Stockfish but because it monopolizes the processors - which I think is what it should do if you are testing multiple programs on the same machine. But maybe it's a little of both.

I cannot say for sure that spinning has an impact on cores being used by other programs, but I know that general processor usage has an impact on the other cores - although the newer chips have less of a problem with this. The reason is that some resources such as cache is shared between cores - even though an attempt is made to minimize the impact on performance for doing this.

[michiguel]

Miguels suggestion here is the best in my opinion because it is explicit. There would be no ambiguity with "Idle Threads" = spin/sleep

Yes, this is a good suggestion, unfortunately the option is of boolean kind, IOW its value can be only true/false

I think you can use "combo" in the uci option

option name Idle Threads type combo default spin var spin var sleep

You can convert it into a boolean internally.

If the most important criteria is to give the user something that can relate to, maybe an alternative to consider could be

"Idle Threads" = responsive/aggressive

or something like that. Maybe that will detach it from technical issues that they are not interested in. Or course "responsive" means "sleeping threads" here.

If you really want it boolean,

"SMP responsive mode" = on/off

I think that the lists in which the options are listed are more intuitive than the ones with on/off, but I guess this is a matter of taste.

Miguel

[Matthias Gemuh]

... Of course "responsive" means "sleeping threads" here.

...

Miguel

The lay man would think "responsive" means
"able to respond, therefore NOT sleeping".

Matthias.

[Graham Banks]

... Of course "responsive" means "sleeping threads" here.

...

Miguel

The lay man would think "responsive" means
"able to respond, therefore NOT sleeping".

Matthias.

Correct.

[Modern Times]

What a mess....

Idle Threads Sleep = true/false

Is clear enough, and the parameter can be explained in the readme file. Personally I am not clear on what effect this has on the other engine when playing ponder off games. And what the default behaviour is for other engines

[syzygy]

Personally I am not clear on what effect this has on the other engine when playing ponder off games.

Unless the other engine "cheats" by somehow using the cpu in non-ponder mode when it is not its turn, the option will have no effect whatsoever on the other engine.

In non-ponder mode, the Stockfish threads, and the threads of any other engine that is not buggy, will sleep (and therefore not use any resources) when the other side is to move.

[Don]

Personally I am not clear on what effect this has on the other engine when playing ponder off games.

Unless the other engine "cheats" by somehow using the cpu in non-ponder mode when it is not its turn, the option will have no effect whatsoever on the other engine.

In non-ponder mode, the Stockfish threads, and the threads of any other engine that is not buggy, will sleep (and therefore not use any resources) when the other side is to move.

It's only in ponder mode where this can be a factor - but I'm not even sure of that. In ponder mode if you do not utilize all your threads you (at least slightly) relieve the working threads of the competing program of the burden of sharing resources. However I don't know if a spinning lock has enough impact or even any impact on this since it is not heavily competing for any resources that are shared.

The experiment you can do on a quad to see this is to run a chess program on two threads and take some sort of timing. Then try the same experiment but do 2 identical timings simultaneously. You will see that these timings go more slowly because all 4 cores are sharing resources. So it's best in a competitive situation to try to keep all the cores you have been allocated busy doing something meaningful - not just for your benefit but to keep the opponent program from getting resources that belong to you.