`Instant + Duration` produce wrong result on aarch64-apple-darwin

[wangrunji0408]

I tried this code on M1 macOS:

use std::time::{Duration, Instant};
fn main() {
    let t0 = Instant::now();
    let t1 = t0 + Duration::from_nanos(50);
    let d = t1 - t0;
    dbg!(t0, t1, d);
    assert_eq!(t0 + d, t1);
}

It's expected to succeed.

Instead, this happened:

[src/main.rs:6] t0 = Instant {
    t: 147092181000,
}
[src/main.rs:6] t1 = Instant {
    t: 147092181001,
}
[src/main.rs:6] d = 41ns
thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `Instant { t: 147092181000 }`,
 right: `Instant { t: 147092181001 }`', src/main.rs:7:5

It seems that there is something wrong with the Duration -> Instant casting in Rust std:

rust/library/std/src/sys/unix/time.rs

Lines 227 to 232 in 1d6f242

	fn checked_dur2intervals(dur: &Duration) -> Option<u64> {
	let nanos =
	dur.as_secs().checked_mul(NSEC_PER_SEC)?.checked_add(dur.subsec_nanos() as u64)?;
	let info = info();
	Some(mul_div_u64(nanos, info.denom as u64, info.numer as u64))
	}

This problem does not exist on x86_64-apple-darwin, because info.denom = info.numer = 1.

Meta

rustc --version --verbose:

rustc 1.56.1 (59eed8a2a 2021-11-01)
binary: rustc
commit-hash: 59eed8a2aac0230a8b53e89d4e99d55912ba6b35
commit-date: 2021-11-01
host: aarch64-apple-darwin
release: 1.56.1
LLVM version: 13.0.0

[hkratz]

@rustbot label +T-libs +O-macos +O-arm

[csmoe]

Seems related to the time resolution difference on Apple M1, cc https://eclecticlight.co/2020/09/08/changing-the-clock-in-apple-silicon-macs/

[hkratz]

The reason for this behavior is that Instant uses platform-specific resolution while Duration uses nanosecond resolution. For Macos x86-64 and Linux this does not matter because on those platforms the resolution of Instant is also nanoseconds.

Instant resolution on my M1 is 125 / 3 ≈ 41.67 ns. So when you add 50 ns to t0 you are adding 1 to its internal representation (= ~41.67 ns). When the duration is calculated it gets rounded down to d = ⌊1 * 125 / 3⌋ = 41 ns. t0 + d = t0 because 41 ns is less than the minimum resolution.

[wangrunji0408]

The reason for this behavior is that Instant uses platform-specific resolution while Duration uses nanosecond resolution. For Macos x86-64 and Linux this does not matter because on those platforms the resolution of Instant is also nanoseconds.

Instant resolution on my M1 is 125 / 3 ≈ 41.67 ns. So when you add 50 ns to t0 you are adding 1 to its internal representation (= ~41.67 ns). When the duration is calculated it gets rounded down to d = ⌊1 * 125 / 3⌋ = 41 ns. t0 + d = t0 because 41 ns is less than the minimum resolution.

So is it considered a bug? Should we round 41 ns up to 1?

[hkratz]

Thought about this some more.

We allow those operations:

• Duration = Instant - Instant
• Instant = Instant + Duration
• bool = Instant == Instant

That can't be changed, so simple arithmetic identities such as i0 + (i1 - i0) == i1 should hold if there is no overflow. In particular because the current behavior leads to real bugs.

The only way to achieve this is IMHO to change the internal representation for Instant on MacOS to nanosecond resolution because otherwise the resolution of the machine timer influences Instant/Duration arithmetic.

cc @thomcc What do you think?

[thomcc]

We should do this, but I'm not sure we can do it everywhere — clock_gettime_nsec_np (and the other clock_gettime functions) is only available in Darwin 16 (macOS 10.12, iOS 10) and newer, which is newer than our supported versions.

We can certainly do it on macOS+aarch64 targets though, since those should always have it.

[BGR360]

This seems pretty severe. I'm a novice contributor, but I do have an M1 device if there's anything I can do to aid the development of a fix here.

Also, should this get some sort of I-prioritize doohickey?