Configurable CPU usage

[arisu3]

The GROMACS cores already support this feature by passing the -cpu flag to it with an integer that is interpreted as a percentage of allowable CPU time (for example, -cpu 50 will limit CPU usage to 50% across all folding threads). The v8 client does not currently support this, but implementation would be trivial as the heavy work has already been done by the core.

The current situation, where usage is determined entirely by thread count, leads to a number of problematic situations:

• Selecting fewer threads causes each core to boost higher, producing more heat. Depending on the hardware, this inversion in expected behavior can occur at a thread count as high as four. A user's attempt to decrease noise can paradoxically increase it.
• Power usage increases at a rate proportional to clock frequency cubed even in the best of conditions. On the same system, four cores running at 4 GHz will use far more power than eight cores running at 2 GHz, despite getting roughly the same PPD.
• Changing thread count is a coarse-grained way to adjust power usage, effectively preventing users with a low core count from adjusting CPU usage without running into minimum thread count limits or bringing cores into single-core boost.
• Projects optimized for a certain number of threads may find themselves suddenly running greater than or fewer than what they were meant for, increasing the domain decomposition overhead and increasing the risk of failures.

Ultimately, it would probably be best for the thread count selection to be moved to the advanced configuration section for users who have very high core count systems or who have particular niche use cases, such as running two folding projects on separate NUMA nodes.

For the average user, CPU usage as a percentage of total CPU time better approximates the user's mental model of what the UI is allowing them to do. For now, I believe it would be best to start by adding support for CPU usage to be configured via the WS API and config file.

I am happy to write a PR myself.

[muziqaz]

One problem if this setting is left in non advanced section while CPU slider is moved to advanced:
Fahcore8/9 do not scale perfectly, and if user only has percentage to work with, they will be reducing their hardware performance throughout by a lot.
I agree that CPU slider coupled with CPU usage setting would benefit, but leaving percentage only, will not.
User might have 32 thread CPU, they further reduce percentage to 50%, so instead of badly scaling fast 32 thread CPU they now have very slow badly scaling CPU folding.
There is a reason why desktop CPUs are topping FAH performance charts, because frequency pushes them to the top compared to high core count Threadrippers or server CPUs.
Or take some server CPUs, which are relatively slow per core compared to desktop CPUs, user further reduces percentage, and now they have disastrously slow badly scaling CPU folding.
Since V8 has launched, and even during v7 days, we rarely seen anyone moan that CPU thread count setting is not enough.

Also, keep in mind, the less the core is loaded the higher it boosts, so power usage saving might not be that visible.
In order for user to save some power they probably should start with turbo boost tech disabling in the BIOS

[arisu3]

In my testing, with the exception of extremely high core count systems (which I would argue count as advanced usage), reducing CPU usage by 50% is better in terms of efficiency than reducing the number of threads in use by 50%. The overall efficiency gain would be worth it.

I think it would be fine to leave the thread count slider in the normal settings, but most people won't need to touch it unless they have particularly large systems. Whether it moves or not is a UI question that I'm probably not the best to answer.

[muziqaz]

More options is better, we just don't need a feature which works halfway and just confuses end user of its abilities.
As I said on Slack, this feature might not work as expected because modern CPUs are performance at all costs first. And they will boost higher the less the core is loaded.
Same is true with limiting core count.
Limiting core count is more for system responsiveness and accommodate the CPUs, rather than efficiency.
If you have all cores folding at limited 50% for each core, then any task outside of the FAH will slow down FAH even more as it trashes the cache subsystem, among other things including Gromacs core issues

[arisu3]

At least with 16 cores and under, it seems there is a benefit to reducing CPU usage despite reduced cache hotness. With above 32 cores, it's a wash, or at least the difference is hiding in noise.

For improving responsiveness, why not fold under the SCHED_IDLE policy? On Linux, any process under that policy will only run if no other tasks are runnable (i.e. if otherwise the idle kthread would be run). Does Windows have anything like that?

[muziqaz]

Windows is a lottery. Their scheduler is built from hopes and dreams.
Either way, this can be implemented and good explanation tool tip should be written regarding this feature for people not to come back to us and keep asking what is the difference between this or that

[marcosfrm]

At least with 16 cores and under, it seems there is a benefit to reducing CPU usage despite reduced cache hotness. With above 32 cores, it's a wash, or at least the difference is hiding in noise.

For improving responsiveness, why not fold under the SCHED_IDLE policy? On Linux, any process under that policy will only run if no other tasks are runnable (i.e. if otherwise the idle kthread would be run). Does Windows have anything like that?

cbang git:
CauldronDevelopmentLLC/cbang@da4890c

[arisu3]

Thanks. I guess Windows does have an equivalent, although I use SCHED_BATCH personally which improves responsiveness on modestly-busy interactive systems by nearly the same amount that SCHED_IDLE does.