rdtsc 用于基准测试和时间戳计数器频率的准确性

Question

作为基准测试任务的一部分，我正在研究可用于测量经过时间的不同机制。我已经最终确定使用clock_gettime，但我也确实使用RDTSC 指令进行了充分的研究和测试。我有几个相同的问题（基于我在几个在线线程上阅读的内容）：

• 在较新的处理器 (>Pentium 4) 上，TSC 以系统上 CPU 的最大频率运行。它是否正确？在那种情况下，使用滴答数和频率来确定时间是否有效？

• 如果上述情况属实，则表示 TSC 不受因省电和其他功能而导致的 CPU 频率变化的影响。知道这一点，这是否意味着使用RDTSC 获得的总滴答声不是采样代码使用的实际滴答声——因为代码将以 CPU 的频率运行，而不是 TSC 的频率？另外，这是否意味着使用TSC ticks和CPU频率得到的时间不是代码段实际使用的时间？

• 我发现许多关于跨内核同步 TSC 值的不同说法（请参阅 this thread）。我不确定什么是正确的，我猜它也取决于处理器型号。但是可以假设它在较新的 CPU 上的内核之间是同步的吗？ （这是不使用sched_set_affinity）？

请注意，由于与之相关的各种问题（便携性、可靠性等），我没有使用RDTSC。这些问题只是为了提高我对 TSC 的工作原理和一般基准测试的理解。

Answer 1

根据英特尔的说法，不变的 TSC 意味着

不变的 TSC 将在所有 ACPI P-、C- 中以恒定速率运行。和 T 状态。

但那是什么比率？嗯，

该比率可能由 处理器的最大核心时钟与总线时钟的比率，或者可以由最大解析频率设置 处理器被引导。最大分辨频率可能与最大合格频率不同 处理器的频率，有关详细信息，请参阅第 18.14.5 节。在某些处理器上，TSC 频率可能 与品牌字符串中的频率不同。

在我看来，好像他们希望它是品牌字符串中的频率，但不知何故并不总是正确.. 那个频率是多少？

TSC、IA32_MPERF 和 IA32_FIXED_CTR2 以相同的平台最大解析频率运行，该频率等于可扩展总线频率与最大解析总线比率的乘积。
对于基于英特尔酷睿微架构的处理器，可扩展总线频率在 (0CDH) 的位字段 MSR_FSB_FREQ[2:0] 中编码，请参见附录 B，“特定于型号的寄存器 (MSR)”。可从以下位域读取最大解析总线比率：
如果禁用 XE 操作，则可以在 MSR_PLATFORM_ID[12:8] 中读取最大解析总线比率。它对应于最大合格频率。
如果开启 XE 操作，最大解析总线比率在 MSR_PERF_STAT[44:40] 中给出，它对应于 BIOS 配置的最大 XE 操作频率。

不过，这可能不是很有帮助。 TL；DR，以编程方式查找 TSC 费率太费力了。当然，您可以在自己的系统上轻松找到它，只需根据定时循环进行不准确的猜测并获取“有意义的最近数字”。无论如何，它可能是品牌字符串中的数字。它已经在我测试过的所有系统上，但我没有测试过那么多。如果不是，那么这将是一些显着不同的速率，所以你肯定会知道。

另外，这是否意味着使用TSC ticks和CPU频率得到的时间不是代码段实际使用的时间？

是的，但并非所有希望都消失了，使用 TSC 滴答声和 TSC 速率 获得的时间（如果你知道的话）将给出实际时间.. 几乎？这里通常会喷出很多关于不可靠性的 FUD。是的，RDTSC 没有序列化（但您可以添加序列化指令）。 RDTSCP 正在序列化，但在某些方面还不够（它不能执行得太早，但它可以执行得太晚）。不过也不是不能用，你要么接受一个小的错误，要么阅读我下面链接的论文。

但是可以假设它在较新 CPU 上的内核之间同步吗？

是的，不，也许 - 它将被同步，除非 TSC 被写入。谁知道，有人可能会这样做。不受你的控制。它也不会在不同的套接字之间同步。

最后，在基准测试的背景下，我并不真正相信关于 RDTSC(P) 的 FUD。您可以根据需要对其进行序列化，TSC 是不变的，并且您知道速率，因为它是您的系统。实际上也没有任何替代方案，它基本上是高分辨率时间测量的来源，最终其他一切最终都会使用。即使没有特殊的预防措施（但过滤您的数据），大多数基准测试的准确性和精度都很好，如果您需要更多然后阅读How to Benchmark Code Execution Times on Intel® IA-32 and IA-64 Instruction Set Architectures，他们编写了一个内核模块，这样他们就可以摆脱其他两个基准错误来源受到很多 FUD、抢占和中断的影响。