linux - 使用 clock_gettime(CLOCK_MONOTONIC) 在 CPU 间移动线程

Question

我听说有人提示说，当操作系统决定将调用线程移动到新的物理 CPU 时，WinAPI 函数 QueryPerformanceFrequency() 和 QueryPerforamnceCounter() 的行为可能不稳定。

有人知道 clock_gettime(CLOCK_MONOTONIC) 是否遇到类似问题吗？还是更能保证稳定？

此外，对 WinAPI 上的 QPF/QPC 的担忧是否已成为过去？还是时至今日他们仍然担心？

Answer 1

运算符(operator):

I've heard people complain that the WinAPI functions QueryPerformanceFrequency() and QueryPerforamnceCounter() can behave erratically and unstably when the OS decides to move the calling thread to a new physical CPU.

我不确定您所说的“不稳定”或“不稳定”是什么意思。如果您指的是漂移或内核之间的差异，这些问题可能是基于 12-15 年前发售的计算机(基于 XP 和 Win2000 的操作系统)。来自微软:

QPC is available on Windows XP and Windows 2000 and works well on most systems. However, some hardware systems' BIOS didn't indicate the hardware CPU characteristics correctly (a non-invariant TSC), and some multi-core or multi-processor systems used processors with TSCs that couldn't be synchronized across cores. Systems with flawed firmware that run these versions of Windows might not provide the same QPC reading on different cores if they used the TSC as the basis for QPC.

对于大多数当前的硬件来说，这几乎已经不是问题(见下面的链接)。

运算符(operator):

Does anybody know if clock_gettime(CLOCK_MONOTONIC) suffers from similar issues? Or is it more guaranteed to be stable?

好吧，任何高频时钟都必须来自某处。在 Windows 机器上(因为您询问了 QPC)，该值从何而来？在对 QueryPerformanceCounter 的任何调用中添加一个额外的层，本质上保证精度降低，因为在“now”和“now as reported”之间的混合中将有更多的 CPU 指令由操作系统返回给您”(虽然极不可能，但抢占的可能性会略有增加，从而进一步降低精度)。

这同样适用于任何基于 Intel 的 Linux/BSD/任何机器，因为它们必须以相同的硬件特性运行。在 Intel 架构世界中，您可以获得的最高频率将是基于 RDTSC 的值，并且操作系统会尽最大努力使任何 TSC 值在内核或处理器之间尽可能接近(至少在没有专门的硬件)。

这就是为什么任何基准测试都应该是基于大量数据点的平均性能预期。

Microsoft 实际上有一份相当不错的文档概述了高频定时器的实现特性，包括 HPET 和 ACPI 电源管理时间，并简要介绍了多时钟和虚拟化:http://msdn.microsoft.com/en-us/library/windows/desktop/dn553408(v=vs.85).aspx .

运算符(operator):

Also, are the worries about QPF/QPC on WinAPI just a thing of the past? Or are they still concerns even today?

对于世界上的大多数人来说，是的。我在基于服务器的代码上工作，其中 微秒 很重要(高频市场数据)，但大多数认为几百微秒就能成就或破坏他们的程序的人都是在自欺欺人。您知道提供一个网页需要多长时间吗？即使有成千上万的用户，CPU 本身也会厌倦所有等待。