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

概述作为基准测试任务的一部分,我正在研究可用于测量经过时间的不同机制.我已经完成了使用clock_gettime的工作,但我也确实对RDTSC指令进行了充分的研究和测试.我有几个相同的问题(基于我在几个在线线程上读到的内容)：>在较新的处理器(> Pentium 4)上,TSC以系统上CPU的最大频率进行计时.它是否正确？在这种情况下,使用滴答数和频率来确

作为基准测试任务的一部分,我正在研究可用于测量经过时间的不同机制.我已经完成了使用clock_gettime的工作,但我也确实对RDTSC指令进行了充分的研究和测试.我有几个相同的问题(基于我在几个在线线程上读到的内容)：

>在较新的处理器(> Pentium 4)上,TSC以系统上cpu的最大频率进行计时.它是否正确？在这种情况下,使用滴答数和频率来确定时间是否有效？
>如果上述情况属实,则表示由于省电和其他功能,TSC不受cpu频率变化的影响.知道这一点,是否意味着使用RDTSC获得的总滴答数不是采样的代码段使用的实际滴答 – 因为代码将以cpu的频率而不是TSC的频率运行？此外,这是否意味着使用TSC滴答获得的时间和cpu频率不是代码片使用的实际时间？
>我发现了很多关于跨核心同步TSC值的不同陈述(见this thread).我不确定什么是正确的,我猜这也取决于处理器型号.但是可以假设它在新cpu的内核之间同步吗？ (这不使用sched_set_affinity)？

请注意,由于与之相关的各种问题(便携性,可靠性等),我没有使用RDTSC.这些问题只是为了提高我对TSC如何工作以及一般基准测试的理解.最佳答案根据英特尔的说法,不变的TSC意味着

The invariant TSC will run at a constant rate in all ACPI P-,C-. and T-states.

但那是多少？好,

That rate may be set by the
maximum core-clock to bus-clock ratio of the processor or may be set by the maximum resolved frequency at
which the processor is booted. The maximum resolved frequency may differ from the maximum qualifIEd
frequency of the processor,see Section 18.14.5 for more detail. On certain processors,the TSC frequency may
not be the same as the frequency in the brand string.

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

The TSC,IA32_MPERF,and IA32_FIXED_CTR2 operate at the same,maximum-resolved frequency of the platform,which is equal to the product of scalable bus frequency and maximum resolved bus ratio.
For processors based on Intel Core microarchitecture,the scalable bus frequency is encoded in the bit fIEld MSR_FSB_FREQ[2:0] at (0CDH),see Appendix B,“Model-Specific Registers (MSRs)”. The maximum resolved bus ratio can be read from the following bit fIEld:
If XE operation is Disabled,the maximum resolved bus ratio can be read in MSR_PLATFORM_ID[12:8]. It corresponds to the maximum qualifIEd frequency.
If XE operation is enabled,the maximum resolved bus ratio is given in MSR_PERF_STAT[44:40],it corresponds to the maximum XE operation frequency configured by BIOS.

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

In addition,does this mean the time obtained by using the TSC ticks and cpu frequency isn’t the actual time used by the code pIEce?

是的,然而并非所有希望都失去了,使用TSC滴答和TSC费率(如果你以某种方式知道它)获得的时间将给出实际时间……几乎？这里通常会发出大量关于不可靠性的FUD.是的,RDTSC没有序列化(但您可以添加序列化指令). RDTSCP正在序列化,但在某些方面还不够(它不能太早执行,但它执行得太晚).但它不是你不能使用它们,你可以接受一个小错误,或阅读我下面链接的论文.

But can it be assumed to be synchronized among cores on newer cpus?

是的,不,也许 – 它将被同步,除非写入TSC.谁知道,有人可能会这样做.你无法控制.它也不会在不同的套接字之间同步.

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

以上是内存溢出为你收集整理的linux – 用于基准测试和时间戳计数器频率的rdtsc的准确性全部内容，希望文章能够帮你解决linux – 用于基准测试和时间戳计数器频率的rdtsc的准确性所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。