`iter_mut` is slightly slower than code with a manual for loop

[hkBst]

Code using iter_mut is slightly slower than code with a manual for loop. Today's nightly results:

$ cargo bench
    Finished `bench` profile [optimized] target(s) in 0.01s
     Running unittests src/lib.rs (target/release/deps/bench_round_up-6e3523a74735e3c8)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running benches/bench.rs (target/release/deps/bench-f02e501c16b73b8b)

running 2 tests
test bench_round_up_for  ... bench:     730,833.00 ns/iter (+/- 1,163.95)
test bench_round_up_iter ... bench:     740,568.00 ns/iter (+/- 1,857.11)

test result: ok. 0 passed; 0 failed; 0 ignored; 2 measured; 0 filtered out; finished in 0.88s

The functions:

pub fn round_up_iter(d: &mut [u8]) -> Option<u8> {
    match d.iter().rposition(|&c| c != b'9') {
        Some(i) => {
            // d[i+1..n] is all nines
            d[i] += 1;
            d.iter_mut().skip(i + 1).for_each(|c| *c = b'0');
            None
        }
        None if d.is_empty() => {
            // an empty buffer rounds up (a bit strange but reasonable)
            Some(b'1')
        }
        None => {
            // 999..999 rounds to 1000..000 with an increased exponent
            d[0] = b'1';
            d.iter_mut().skip(1).for_each(|c| *c = b'0');
            Some(b'0')
        }
    }
}

pub fn round_up_for(d: &mut [u8]) -> Option<u8> {
    match d.iter().rposition(|&c| c != b'9') {
        Some(i) => {
            // d[i+1..n] is all nines
            d[i] += 1;
            for j in i + 1..d.len() {
                d[j] = b'0';
            }
            None
        }
        None if d.len() > 0 => {
            // 999..999 rounds to 1000..000 with an increased exponent
            d[0] = b'1';
            for j in 1..d.len() {
                d[j] = b'0';
            }
            Some(b'0')
        }
        None => {
            // an empty buffer rounds up (a bit strange but reasonable)
            Some(b'1')
        }
    }
}

This holds even if the order of match arms is the same.

[hkBst]

Godbolt shows shorter code for iter_mut, but apparently it isn't better...

[the8472]

.skip().for_each() goes through the slice fold impl, which is one of the most optimization-golfed pieces of code in iterators, so it's not particularly surprising.

rust/library/core/src/slice/iter/macros.rs

Lines 235 to 265 in 6c0a912

	fn fold<B, F>(self, init: B, mut f: F) -> B
	where
	F: FnMut(B, Self::Item) -> B,
	{
	// this implementation consists of the following optimizations compared to the
	// default implementation:
	// - do-while loop, as is llvm's preferred loop shape,
	// see https://releases.llvm.org/16.0.0/docs/LoopTerminology.html#more-canonical-loops
	// - bumps an index instead of a pointer since the latter case inhibits
	// some optimizations, see #111603
	// - avoids Option wrapping/matching
	if is_empty!(self) {
	return init;
	}
	let mut acc = init;
	let mut i = 0;
	let len = len!(self);
	loop {
	// SAFETY: the loop iterates `i in 0..len`, which always is in bounds of
	// the slice allocation
	acc = f(acc, unsafe { & $( $mut_ )? *self.ptr.add(i).as_ptr() });
	// SAFETY: `i` can't overflow since it'll only reach usize::MAX if the
	// slice had that length, in which case we'll break out of the loop
	// after the increment
	i = unsafe { i.unchecked_add(1) };
	if i == len {
	break;
	}
	}
	acc
	}

Edit: wait, for loop is faster? that's unexpected.

[folkertdev]

Based on the LLVM IR https://godbolt.org/z/xncPT5G57, it might be the difference between icmp samesign eq (for_each) versus icmp ult i64 (explicit for). At least when I change that manually and feed the IR to clang it generates assembly that is much closer to the for-loop version.

[folkertdev]

Actually, on my machine the for_each version is quite a bit faster

     Running benches/bench.rs (target/release/deps/bench-75b29fbcb1b8b7ec)

running 2 tests
test bench_round_up_for  ... bench:     458,688.40 ns/iter (+/- 18,512.18)
test bench_round_up_iter ... bench:     343,654.65 ns/iter (+/- 12,953.56)

test result: ok. 0 passed; 0 failed; 0 ignored; 2 measured; 0 filtered out; finished in 1.45s

with

cargo 1.90.0-nightly (6833aa715 2025-07-13)
release: 1.90.0-nightly
commit-hash: 6833aa715d724437dc1247d0166afe314ab6854e
commit-date: 2025-07-13
host: x86_64-unknown-linux-gnu
libgit2: 1.9.1 (sys:0.20.2 vendored)
libcurl: 8.14.1-DEV (sys:0.4.82+curl-8.14.1 vendored ssl:OpenSSL/3.5.0)
ssl: OpenSSL 3.5.0 8 Apr 2025
os: Linux Mint 22.0.0 (wilma) [64-bit]

[hkBst]

@folkertdev interesting! My measurements are also on x86_64 (dev-desktop-eu-2).

rustc 1.90.0-nightly (e46629662 2025-07-17)
binary: rustc
commit-hash: e4662966273ed58b51f9ff8d682accc202aa1210
commit-date: 2025-07-17
host: x86_64-unknown-linux-gnu
release: 1.90.0-nightly
LLVM version: 20.1.8

[hkBst]

On aarch64 I also get that iter_mut is faster:

running 2 tests
test bench_round_up_for  ... bench:   1,056,714.50 ns/iter (+/- 3,548.12)
test bench_round_up_iter ... bench:     856,936.00 ns/iter (+/- 2,326.88)

test result: ok. 0 passed; 0 failed; 0 ignored; 2 measured; 0 filtered out; finished in 0.58s

with

rustc 1.90.0-nightly (2a023bf80 2025-07-10)
binary: rustc
commit-hash: 2a023bf80a6fbd6a06d5460a34eb247b986286ed
commit-date: 2025-07-10
host: aarch64-unknown-linux-gnu
release: 1.90.0-nightly
LLVM version: 20.1.7

[the8472]

Note that these things can heavily depend on optimization settings. LTO, 1CGU, target-cpu, etc.

[clarfonthey]

Potentially #122971 might be a fix for this?