Feature: Allow for number of threads regardless of detected core count

[tepozoa]

Currently in cli.rs / main.rs the code is using the number of cores detected to determine how many threads to spawn. This is incompatible with using systemd-run to limit the CPU resources to maximize search while minimizing heat generation. For example on an 8 core system:

systemd-run --user --pty --wait --property=CPUQuota=400% target/release/rana -n=aaaaaa -g 12

...rana will spawn only 4 threads running at 100% each as systemd artificially shows the process only 4 cores exist. Given this CPU has 8 cores (hyperthreads). the desire instead is to run 8 threads at 50% on all 8 cores (which systemd will do for us with the above property set) - this spreads out the heat and maximizes return value better than running 4 @ 100% (I did a lot of work testing BOINC tasks which uses the same design methods - there's something magical about running more threads at lower speed than fewer threads at max speed. I suspect it has to do with L2 caching or somesuch.

It would be handy if a user controlled switch -t / --threads could be specified which is allowed to be larger (or smaller!) than the detected core count. The help text should probably say something like "Only use this with systemd CPUQuota settings" or somesuch to alert the user as to it's danger etc.

Thanks for considering.

[tepozoa]

Quick PoC by just hacking the code based on my system:

Hard set 8 cores, run at 50% per core:

$ vim main.rs -> for _ in 0..8 {
$ cargo build --release
$ systemd-run --user --pty --wait --property=CPUQuota=400% target/release/rana -n=aaaaaa -g 12

Observation:

$ top

top - 10:57:36 up  3:18,  2 users,  load average: 5.97, 2.95, 2.33
Tasks: 235 total,   3 running, 232 sleeping,   0 stopped,   0 zombie
%Cpu0  : 51.6 us,  0.3 sy,  0.0 ni, 47.7 id,  0.0 wa,  0.3 hi,  0.0 si,  0.0 st 
%Cpu1  : 50.8 us,  0.0 sy,  0.0 ni, 48.8 id,  0.0 wa,  0.0 hi,  0.3 si,  0.0 st 
%Cpu2  : 50.8 us,  0.3 sy,  0.0 ni, 48.2 id,  0.0 wa,  0.3 hi,  0.3 si,  0.0 st 
%Cpu3  : 51.3 us,  0.0 sy,  0.0 ni, 48.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st 
%Cpu4  : 51.3 us,  0.7 sy,  0.0 ni, 47.4 id,  0.3 wa,  0.3 hi,  0.0 si,  0.0 st 
%Cpu5  : 51.3 us,  0.3 sy,  0.0 ni, 48.4 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st 
%Cpu6  : 51.0 us,  0.0 sy,  0.0 ni, 48.7 id,  0.0 wa,  0.3 hi,  0.0 si,  0.0 st 
%Cpu7  : 52.3 us,  0.0 sy,  0.0 ni, 47.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st 
KiB Mem : 16280872 total, 11908268 free,  2575608 used,  2807984 buff/cache     
KiB Swap: 18623508 total, 18623508 free,        0 used. 13705264 avail Mem 

    PID USER      PR  NI    VIRT    RES  %CPU  %MEM     TIME+ S COMMAND         
  14755 tepozoa   20   0  534.0m   4.1m 398.7   0.0   8:57.61 S rana            

[grunch]

Currently in cli.rs / main.rs the code is using the number of cores detected to determine how many threads to spawn. This is incompatible with using systemd-run to limit the CPU resources to maximize search while minimizing heat generation. For example on an 8 core system:

systemd-run --user --pty --wait --property=CPUQuota=400% target/release/rana -n=aaaaaa -g 12

...rana will spawn only 4 threads running at 100% each as systemd artificially shows the process only 4 cores exist. Given this CPU has 8 cores (hyperthreads). the desire instead is to run 8 threads at 50% on all 8 cores (which systemd will do for us with the above property set) - this spreads out the heat and maximizes return value better than running 4 @ 100% (I did a lot of work testing BOINC tasks which uses the same design methods - there's something magical about running more threads at lower speed than fewer threads at max speed. I suspect it has to do with L2 caching or somesuch.

It would be handy if a user controlled switch -t / --threads could be specified which is allowed to be larger (or smaller!) than the detected core count. The help text should probably say something like "Only use this with systemd CPUQuota settings" or somesuch to alert the user as to it's danger etc.

Thanks for considering.

Hi! sorry for the delay on this response, this is a great idea, I agree with you, are you a dev? can you start working on this issue?

[tepozoa]

Hi! sorry for the delay on this response, this is a great idea, I agree with you, are you a dev? can you start working on this issue?

Alas, not a dev (and especially not rust :) ). I can read code and hack around just following my nose but don't actually delve into real, actual programming (C, rust, go, etc.) beyond knowing how to read it, infer the logic and compile.

[grunch]

We can wait for some contribution, sometimes miracles happen 😅