nproc: simplify core count

[oech3]

No description provided.

[codspeed-hq]

Merging this PR will not alter performance

✅ 323 untouched benchmarks
⏩ 46 skipped benchmarks¹

---

_{Comparing oech3:nproc-1 (f464f23) with main (8f1214b)}

Footnotes

1. 46 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[max-amb]

Is this at risk of an underflow? num_cpus_all() returns a usize, so if we subtract a usize from a usize we risk underflow. It may be completely mitigated by the .max() call but the compiler doesn't like it:

fn main() {
    let x: usize = 5;
    dbg!((x-6).max(1));
}

fails to compile.

Could use a saturating_sub?

[oech3]

Available on 64-bit only.

[max-amb]

Ah yeah, could cast to a signed type, or I think the original is the only solution. wdyt? Maybe something more obvious is

    let initial_cores = std::cmp::min(limit, cores);
    let cores = if initial_cores <= ignore {
        1
    } else {
        initial_cores - ignore
    }

[max-amb]

But will it not panic?

[max-amb]

When compiled in release it will wrap and we get the wrapped number as it is bigger? I'm not too familiar with this though.

https://doc.rust-lang.org/book/ch03-02-data-types.html#integer-overflow

It panics in debug mode

[oech3]

It seems working on 32bit too.

[github-actions]

GNU testsuite comparison:

Skip an intermittent issue tests/tail/tail-n0f (fails in this run but passes in the 'main' branch)
Skipping an intermittent issue tests/tail/retry (passes in this run but fails in the 'main' branch)

[max-amb]

Suggested change

	cores = cores.saturating_sub(ignore).clamp(1, limit);
	cores = (cores.min(limit).saturating_sub(ignore)).max(1);

As from https://docs.rs/num/latest/num/fn.clamp.html, we have that clamp

Panics in debug mode if !(min <= max).

Not great for testing.

[oech3]

Hmm

[cakebaker]

limit is always 1 or greater, see lines 31 - 42.

[oech3]

Does Ok(n) => n, not be -1?

[oech3]

I'll explicit usize at parse(). OK?

[cakebaker]

I think that's not necessary: we already use usize::MAX in the other arm and so it is obvious that n is of type usize.

[oech3]

Now we have

coreutils/src/uu/nproc/src/nproc.rs

Lines 25 to 29 in 1b912dc

	let limit = env::var("OMP_THREAD_LIMIT")
	.ok()
	.and_then(|v| v.parse().ok())
	.filter(|&n| n > 0)
	.unwrap_or(usize::MAX);