assembly - 多个 nop 指令并不总是比单个 nop 指令花费更长的时间

Question

我在 C++ 中使用 rdtsc 为多个 NOP 指令和单个 NOP 指令计时.但是，我没有发现执行 NOP 所需的周期数与执行的 NOP 数量成正比。我很困惑为什么会这样。我的 CPU 是 Intel Core i7-5600U @ 2.60Ghz。

这是代码:

#include <stdio.h>

int main() {
    unsigned long long t;

    t = __rdtsc();
    asm volatile("nop");
    t = __rdtsc() - t;
    printf("rdtsc for one NOP: %llu\n", t);

    t = __rdtsc();
    asm volatile("nop; nop; nop; nop; nop; nop; nop;");
    t = __rdtsc() - t;
    printf("rdtsc for seven NOPs: %llu\n", t);

}

我得到如下值:

rdtsc for one NOP: 78
rdtsc for seven NOPs: 91

rdtsc for one NOP: 78
rdtsc for seven NOPs: 78

在不设置处理器关联的情况下运行时。
设置处理器关联时，如 $ taskset -c 0 ./nop$ ，结果是:

rdtsc for one NOP: 78
rdtsc for seven NOPs: 78

rdtsc for one NOP: 130
rdtsc for seven NOPs: 169

rdtsc for one NOP: 78
rdtsc for seven NOPs: 143

为什么会这样？

Answer 1

您的结果可能是测量噪声和/或频率缩放，因为您在 printf 之后立即启动第二个间隔的计时器。从系统调用返回。

RDTSC 计算引用周期，而不是核心时钟周期，因此您主要是在发现 CPU 频率。 (较低的内核时钟速度 = 对于相同数量的内核时钟运行两条 rdtsc 指令需要更多的引用周期)。你的 RDTSC 指令基本上是背靠背的； nop与rdtsc 的uop 数量相比，指令可以忽略不计。本身解码为(在包括 Broadwell 在内的普通 CPU 上)。

RDTSC 也可以通过乱序执行重新排序。不是这样 nop做任何 CPU 必须等待的事情；它只是将前端从发出第二个 rdtsc 的 uops 延迟了 0.25 或 1.75 个周期。 . (实际上，我不确定微码定序器是否可以在与来自另一条指令的 uop 相同的周期中发送 uops。所以可能是 1 或 2 个周期)。

我在 How to get the CPU cycle count in x86_64 from C++? 上的回答有很多关于 RDTSC 工作原理的背景知识。

您可能需要 pause说明 .它在 Skylake 及更高版本上空闲约 100 个内核时钟周期，或在早期 Intel 内核上空闲约 5 个周期。 或旋转 PAUSE + RDTSC . How to calculate time for an asm delay loop on x86 linux? 显示了一个可能有用的延迟自旋循环，它休眠给定数量的 RDTSC 计数。您需要知道引用时钟速度以将其与纳秒相关联，但它通常在英特尔 CPU 上的额定最大非涡轮时钟附近。例如4.0GHz Skylake 上的 4008 MHz。

如果可用，tpause以 TSC 时间戳作为唤醒时间。 (见链接)。但目前它只是低功耗的 Tremont。

插入 NOP 永远不会起作用 在具有巨大重新排序缓冲区的现代超标量/乱序 x86 上可靠!现代 x86 不是可以计算嵌套延迟循环迭代的微 Controller 。如果周围的代码在前端没有瓶颈，OoO exec 只会隐藏通过管道提供 NOP 的成本。

说明没有成本，你可以加起来 .要对指令的成本进行建模，您需要知道它的延迟、前端 uop 计数以及它需要哪些后端执行端口。以及管道上的任何特殊效果，例如 lfence等待所有以前的 uops 退出，然后才能发布。 How many CPU cycles are needed for each assembly instruction?

另见 What considerations go into predicting latency for operations on modern superscalar processors and how can I calculate them by hand?

请注意，如果缓存未命中，或者甚至可能是非常慢的 ALU 依赖链，则您想要的 ~100ns 的“ sleep ”时间不一定足够长以耗尽无序执行缓冲区(ROB)。 (后者不太可能在人工案例之外)。所以你可能不想做类似 lfence 的事情.