assembly - (rdtsc + lfence + rdtsc)和(rdtsc + rdtscp)在测量执行时间上有什么区别吗？

Question

据我所知，相对于rdtsc和rdtscp指令，处理器中的运行时排序的主要区别在于执行是否要等到所有先前的指令都在本地执行后才能执行。

换句话说，这意味着lfence + rdtsc = rdtscp，因为在rdtsc指令之前的lfence使得在所有先前的指令本地完成之后将执行以下rdtsc。

但是，我看到了一些示例代码，这些代码在测量开始时使用rdtsc，在测量结束时使用rdtscp。使用两个rdtsc和rdtsc + rdtscp之间有什么区别吗？

    lfence
    rdtsc
    lfence
    ...
    ...
    ...
    lfence
    rdtsc
    lfence

    lfence
    rdtsc
    lfence
    ...
    ...
    ...
    rdtscp
    lfence

Answer 1

TL; DR

rdtscp和lfence/rdtsc在Intel处理器上具有完全相同的上游序列化属性。在具有调度序列化lfence的AMD处理器上，两个序列还具有相同的上游序列化属性。关于后续指令，可以分派rdtsc序列中的lfence/rdtsc与后续指令同时执行。如果您还希望精确地安排这些稍后的说明的时间，则可能不需要此行为。这通常是没有问题的，因为只要没有结构性危害，预留站调度程序就会将较旧的优先级分配给优先级进行调度。 lfence退休后，rdtsc uops将是RS中最古老的，可能没有结构性危害，因此将立即派遣它们（可能与一些后来的uops一起）。您也可以在lfence之后放置rdtsc。

英特尔手册V2对rdtscp（强调我的意思）说了以下几点：


RDTSCP指令不是序列化指令，但它确实
等到所有先前的指令已执行并且所有先前的
负载是全局可见的。但是它不等待以前的商店
为了在全局上可见，后续指令可以在执行读取操作之前开始执行。


这里的“读取操作”部分是指读取时间戳计数器。这表明rdtscp在内部类似于lfence，后跟rdtsc +读取IA32_TSC_AUX。也就是说，先执行lfence，然后执行两次从寄存器的读取（可能同时）。

在大多数支持这些指令的Intel和AMD处理器上，lfence/rdtsc的uops数比rdtscp略大。 Agner's tables中提到的lfence微指令的数量是针对lfence指令被背对背执行的情况，这使得lfence似乎被解码为较小的微指令（1或2 ），而不是将单个lfence实际解码为（5或6 oups）。通常，使用lfence时不使用其他连续的lfence。这就是为什么lfence/rdtsc包含比rdtscp更多的uops的原因。 Agner的表还显示，在某些处理器上，rdtsc和rdtscp具有相同的uops数量，我不确定这是正确的。与rdtscp相比，rdtsc具有一个或多个uops更有意义。就是说，延迟可能比uops数量的差异更重要，因为这直接影响测量开销。

在可移植性方面，rdtsc早于rdtscp；奔腾处理器首次支持rdtsc，而第一批支持rdtscp的处理器则于2005-2006年发布（请参阅：What is the gcc cpu-type that includes support for RDTSCP?）。但是，当今使用的大多数Intel和AMD处理器都支持rdtscp。在两个序列之间进行比较的另一个维度是rdtscp比ECX污染了一个寄存器（即rdtsc）。

总而言之，如果您不关心阅读IA32_TSC_AUX MSR，则没有特别大的理由选择一个。我会使用rdtscp并在不支持它的处理器上回退到lfence/rdtsc（或lfence/rdtsc/lfence）。如果要获得最大的计时精度，请使用Memory latency measurement with time stamp counter中讨论的方法。



作为Andreas Abel pointed out，您仍需要在最后一个lfence之后加上一个rdtsc(p)，因为它没有顺序排列。后续说明：

lfence                    lfence
rdtsc      -- ALLOWED --> B
B                         rdtsc

rdtscp     -- ALLOWED --> B
B                         rdtscp

这也是addressed in the manuals。



关于rdtscp的使用，对我来说将其视为紧凑的lfence + rdtsc似乎是正确的。
手册对这两个说明使用了不同的术语（例如，“本地完成”与“全局可见”的负载），但所描述的行为似乎是相同的。
在此答案的其余部分中，我假设是这样。

但是，rdtscp是一条指令，而lfence + rdtscp是两条指令，这使得lfence成为分析代码的一部分。
承认lfence就后端执行资源（它只是一个标记）而言应该是轻量级的，它仍然会占用前端资源（两个uops？）和ROB中的一个插槽。
由于rdtscp具有读取IA32_TSC_AUX的能力，因此被解码为更多的微指令，因此，尽管它节省了前端（部分）资源，但它却更多地占用了后端。
如果首先（或同时）使用处理器ID读取TSC，则此额外内容仅与后续代码有关。
这可能是为什么在基准测试结束时而不是在基准测试开始时使用它的原因（额外的uoop会影响代码）。
这足以使一些微体系结构基准偏差/使其复杂化。

您不能避开lfence之后的rdtsc(p)，但可以避开rdtscp之前的那个。
这对于第一个rdtsc似乎是不必要的，因为无论如何都不会对前面的lfence进行分析。



最后使用rdtscp的另一个原因是（根据Intel的说法）它旨在检测向另一个CPU的迁移（这就是为什么原子地也加载IA32_TSC_AUX的原因），因此在配置文件代码的最后，您可能会想要检查代码是否尚未调度到另一个CPU。


用户模式软件可以使用RDTSCP来检测在连续读取TSC之间是否发生了CPU迁移。


当然，这需要先读取IA32_TSC_AUX（以便进行比较），因此，在性能分析代码之前应先读取rdpid或rdtscp。
如果负担不起不使用ecx，则第一个rdtsc也可以是rdtscp（但请参见上文），否则（而不是在分析的代码中存储处理器ID），可以使用rdpid首先（因此，在分析的代码周围有一个rdtsc + rdtscp对）。

这对ABA problem是开放的，所以我认为Intel在这方面没有强项（除非我们限制自己编写的代码足够短以至于最多只能重新安排一次）。

编辑
正如PeterCordes所指出的那样，从经过时间度量的角度来看，迁移A-> B-> A并不是问题，因为参考时钟是相同的。



有关rdtsc(p)为什么未完全序列化的更多信息：Why isn't RDTSC a serializing instruction? 。