了解 M1 机器上的 DispatchTime

Question

赏金将在 6 天后到期。 此问题的答案有资格获得+500声望赏金。 Bobj-C希望引起对这个问题的更多关注。

在我的 iOS 项目中，能够复制Combine's Schedulers实现，我们有一套广泛的测试，在 Intel 机器上一切正常，所有测试都通过了，现在我们得到了一些 M1 机器，看看我们的工作流程中是否有一个停止器.

突然我们的一些库代码开始失败，奇怪的是即使我们使用 Combine 的实现，测试仍然失败。

我们的假设是我们在滥用DispatchTime(uptimeNanoseconds:) ，正如您在以下屏幕截图中看到的那样（Combine 的实现）

根据文档，我们现在知道使用 uptimeNanoseconds 值初始化DispatchTime并不意味着它们是 M1 机器上的实际纳秒

创建一个相对于自启动以来滴答作响的系统时钟的DispatchTime 。

 - Parameters:
   - uptimeNanoseconds: The number of nanoseconds since boot, excluding
                        time the system spent asleep
 - Returns: A new `DispatchTime`
 - Discussion: This clock is the same as the value returned by
               `mach_absolute_time` when converted into nanoseconds.
               On some platforms, the nanosecond value is rounded up to a
               multiple of the Mach timebase, using the conversion factors
               returned by `mach_timebase_info()`. The nanosecond equivalent
               of the rounded result can be obtained by reading the
               `uptimeNanoseconds` property.
               Note that `DispatchTime(uptimeNanoseconds: 0)` is
               equivalent to `DispatchTime.now()`, that is, its value
               represents the number of nanoseconds since boot (excluding
               system sleep time), not zero nanoseconds since boot.

那么，测试是错误的还是我们不应该像这样使用DispatchTime ？

我们尝试遵循Apple 的建议并使用它：

uint64_t MachTimeToNanoseconds(uint64_t machTime)
{
    uint64_t nanoseconds = 0;
    static mach_timebase_info_data_t sTimebase;
    if (sTimebase.denom == 0)
        (void)mach_timebase_info(&sTimebase);

    nanoseconds = ((machTime * sTimebase.numer) / sTimebase.denom);

    return nanoseconds;
}

它没有多大帮助。

编辑：截图代码：

 func testSchedulerTimeTypeDistance() {
    let time1 = DispatchQueue.SchedulerTimeType(.init(uptimeNanoseconds: 10000))
    let time2 = DispatchQueue.SchedulerTimeType(.init(uptimeNanoseconds: 10431))
    let distantFuture = DispatchQueue.SchedulerTimeType(.distantFuture)
    let notSoDistantFuture = DispatchQueue.SchedulerTimeType(
      DispatchTime(
        uptimeNanoseconds: DispatchTime.distantFuture.uptimeNanoseconds - 1024
      )
    )

    XCTAssertEqual(time1.distance(to: time2), .nanoseconds(431))
    XCTAssertEqual(time2.distance(to: time1), .nanoseconds(-431))

    XCTAssertEqual(time1.distance(to: distantFuture), .nanoseconds(-10001))
    XCTAssertEqual(distantFuture.distance(to: time1), .nanoseconds(10001))
    XCTAssertEqual(time2.distance(to: distantFuture), .nanoseconds(-10432))
    XCTAssertEqual(distantFuture.distance(to: time2), .nanoseconds(10432))

    XCTAssertEqual(time1.distance(to: notSoDistantFuture), .nanoseconds(-11025))
    XCTAssertEqual(notSoDistantFuture.distance(to: time1), .nanoseconds(11025))
    XCTAssertEqual(time2.distance(to: notSoDistantFuture), .nanoseconds(-11456))
    XCTAssertEqual(notSoDistantFuture.distance(to: time2), .nanoseconds(11456))

    XCTAssertEqual(distantFuture.distance(to: distantFuture), .nanoseconds(0))
    XCTAssertEqual(notSoDistantFuture.distance(to: notSoDistantFuture),
                   .nanoseconds(0))
  }

Answer 1

Intel 和 ARM 代码之间的区别在于精度。

使用 Intel 代码， DispatchTime在内部以纳秒为单位工作。 使用 ARM 代码， DispatchTime以纳秒* 3 / 125 （加上一些 integer 舍入）工作。 这同样适用于DispatchQueue.SchedulerTimeType 。

DispatchTimeInterval和DispatchQueue.SchedulerTimeType.Stride内部使用纳秒。

因此，ARM 代码使用较低精度进行计算，但在比较距离时使用全精度。 此外，从纳秒转换为内部单位时，您会失去一些精度。

DispatchTime转换的确切公式为（执行为 integer 操作）：

rawValue = (nanoseconds * 3 + 124) / 125

nanoseconds = rawValue * 125 / 3

举个例子，让我们看这段代码：

let time1 = DispatchQueue.SchedulerTimeType(.init(uptimeNanoseconds: 10000))
let time2 = DispatchQueue.SchedulerTimeType(.init(uptimeNanoseconds: 10431))
XCTAssertEqual(time1.distance(to: time2), .nanoseconds(431))

它导致计算：

(10000 * 3 + 124) / 125 -> 240
(10431 * 3 + 124) / 125 -> 251
251 - 240 -> 11
11 * 125 / 3 -> 458

458 和 431 之间的结果比较然后失败。

所以主要的解决办法是允许小的差异（我还没有验证 42 是否是最大差异）：

XCTAssertEqual(time1.distance(to: time2), .nanoseconds(431), accuracy: .nanoseconds(42))
XCTAssertEqual(time2.distance(to: time1), .nanoseconds(-431), accuracy: .nanoseconds(42))

还有更多惊喜：除了 Intel 代码， distantFuture和notSoDistantFuture等同于 ARM 代码。 它可能是这样实现的，以防止在乘以 3 时发生溢出。（实际计算为：0xFFFFFFFFFFFFFFFF * 3）。

此外，我认为在计算处于或接近 0 的时间戳与处于或接近遥远未来的时间戳之间的距离时，您依赖于实现特定的行为。 测试依赖于遥远的未来在内部使用 0xFFFFFFFFFFFFFFFF 的事实，并且无符号减法环绕并产生一个结果，就好像内部值为 -1。

Answer 2

我认为你的问题在于这一行：

nanoseconds = ((machTime * sTimebase.numer) / sTimebase.denom)

...正在执行 integer 操作。

M1 的实际比率为125/3 ( 41.666... )，因此您的转换因子被截断为41 。 这是一个约 1.6% 的错误，这可能解释了您所看到的差异。