了解 M1 机器上的 DispatchTime

Question

在我的 iOS 项目中，我们能够复制Combine's Schedulers实现，并且我们进行了广泛的测试，在 Intel 机器上一切都很好，所有测试都通过了，现在我们得到了一些 M1 机器来看看我们的工作流程中是否存在阻碍。

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

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

根据文档，我们现在知道DispatchTime用 uptimeNanoseconds 值初始化并不意味着它们是 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的建议并使用它：

 - 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.

这并没有多大帮助。

编辑：截图代码：

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;
}

Answer 1

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

使用英特尔代码，DispatchTime内部以纳秒为单位工作。对于 ARM 代码，它可以使用纳秒* 3 / 125（加上一些整数舍入）。这同样适用于DispatchQueue.SchedulerTimeType.

DispatchTimeInterval并DispatchQueue.SchedulerTimeType.Stride在两个平台上内部使用纳秒。

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

转换的确切公式DispatchTime为（作为整数运算执行）：

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与notSoDistantFutureARM 代码相同。它可能是这样实现的，以防止与 3 相乘时溢出。（实际计算结果为：0xFFFFFFFFFFFFFFFF * 3）。从内部单位到纳秒的转换将得到 0xFFFFFFFFFFFFFFFF * 125 / 3，这个值太大了，无法用 64 位表示。

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