5

不同的进程可以同时运行RDTSC吗？或者这是只有一个核心可以同时操作的资源？TSC 在每个核心中（至少您可以为每个核心单独调整它），所以应该可以。但是超级踩踏呢？

我该如何测试呢？

4

1 回答 1

7

每个物理内核都有自己的 TSC；微代码不必脱离核心，因此它们没有竞争共享资源。完全脱离核心会使它变得更慢，并使实现更加复杂。在每个内核内部都有一个物理计数器是一种更简单的实现，只需计算分配给所有内核的参考时钟信号的滴答声。

使用超线程，共享物理的逻辑内核总是竞争执行资源。从Agner Fog 的指令表中，我们知道 Skylake 上的 RDTSC 是前端 20 uop，每 25 个周期有 1 个吞吐量。在只执行 RDTSC 指令的情况下，每个时钟不到 1 uop，竞争前端可能不是问题。

可能这些微指令中的大多数都可以在任何执行端口上运行，因此两个逻辑线程很可能都可以rdtsc以该吞吐量运行。

但也许他们会竞争一个不完全流水线的执行单元。

您可以通过times 20 rdtsc在一个运行几千万次迭代的循环中对其进行测试，然后在一个核心上单独运行该微基准测试，然后将其运行两次固定到一个物理核心的逻辑核心上。

我很好奇，我自己在 Linuxperf上使用 Skylake i7-6700ktaskset -c 3和taskset -c 7（Linux 枚举此 CPU 上的内核的方式，这些数字是第 4 个物理内核的逻辑内核。您可以检查 /proc/cpuinfo 到在您的系统上查找。）

如果它们几乎同时完成，为了避免交错输出行，我使用 bash 进程替换cat <(cmd1) <(cmd2)来同时运行它们并以固定顺序打印输出。这些命令是 taskset -c 3 perf stat -etask-clock:u,context-switches,cpu-migrations,page-faults,cycles:u,instructions:u,branches:u,branch-misses:u,uops_issued.any:u,uops_executed.thread:u,cpu_clk_thread_unhalted.one_thread_active:u -r2 ./testloop计算核心时钟周期（不是参考周期，所以我不必对涡轮/空闲时钟频率感到偏执）。

testlooptimes 20 rdtsc是一个静态可执行文件，带有一个包含（NASM 重复运算符）和dec ebp/的手写 asm 循环，jnz循环的顶部由 64 对齐，以防万一。在循环之前，mov ebp, 10000000初始化计数器。（请参阅X86 的 MOV 真的可以“免费”吗？为什么我根本不能重现这个？有关我如何以这种方式进行微基准测试的详细信息。或者了解 lfence 对具有两个长依赖链的循环的影响，以增加另一个长度一个简单的 NASM 程序示例，带有一个循环，times用于重复指令。）

 Performance counter stats for './testloop' (2 runs):

          1,278.19 msec task-clock:u              #    1.000 CPUs utilized            ( +-  0.19% )
                 4      context-switches          #    0.004 K/sec                    ( +- 11.11% )
                 0      cpu-migrations            #    0.000 K/sec                  
                 2      page-faults               #    0.002 K/sec                  
     5,243,270,118      cycles:u                  #    4.102 GHz                      ( +-  0.01% )  (71.37%)
       219,949,542      instructions:u            #    0.04  insn per cycle           ( +-  0.01% )  (85.68%)
        10,000,692      branches:u                #    7.824 M/sec                    ( +-  0.03% )  (85.68%)
                32      branch-misses:u           #    0.00% of all branches          ( +- 93.65% )  (85.68%)
     4,010,798,914      uops_issued.any:u         # 3137.885 M/sec                    ( +-  0.01% )  (85.68%)
     4,010,969,168      uops_executed.thread:u    # 3138.018 M/sec                    ( +-  0.00% )  (85.78%)
                 0      cpu_clk_thread_unhalted.one_thread_active:u #    0.000 K/sec                    (57.17%)

           1.27854 +- 0.00256 seconds time elapsed  ( +-  0.20% )


 Performance counter stats for './testloop' (2 runs):

          1,278.26 msec task-clock:u              #    1.000 CPUs utilized            ( +-  0.18% )
                 6      context-switches          #    0.004 K/sec                    ( +-  9.09% )
                 0      cpu-migrations            #    0.000 K/sec                  
                 2      page-faults               #    0.002 K/sec                    ( +- 20.00% )
     5,245,894,686      cycles:u                  #    4.104 GHz                      ( +-  0.02% )  (71.27%)
       220,011,812      instructions:u            #    0.04  insn per cycle           ( +-  0.02% )  (85.68%)
         9,998,783      branches:u                #    7.822 M/sec                    ( +-  0.01% )  (85.68%)
                23      branch-misses:u           #    0.00% of all branches          ( +- 91.30% )  (85.69%)
     4,010,860,476      uops_issued.any:u         # 3137.746 M/sec                    ( +-  0.01% )  (85.68%)
     4,012,085,938      uops_executed.thread:u    # 3138.704 M/sec                    ( +-  0.02% )  (85.79%)
             4,174      cpu_clk_thread_unhalted.one_thread_active:u #    0.003 M/sec                    ( +-  9.91% )  (57.15%)

           1.27876 +- 0.00265 seconds time elapsed  ( +-  0.21% )

与单独跑步：

 Performance counter stats for './testloop' (2 runs):

          1,223.55 msec task-clock:u              #    1.000 CPUs utilized            ( +-  0.52% )
                 4      context-switches          #    0.004 K/sec                    ( +- 11.11% )
                 0      cpu-migrations            #    0.000 K/sec                  
                 2      page-faults               #    0.002 K/sec                  
     5,003,825,966      cycles:u                  #    4.090 GHz                      ( +-  0.00% )  (71.31%)
       219,905,884      instructions:u            #    0.04  insn per cycle           ( +-  0.04% )  (85.66%)
        10,001,852      branches:u                #    8.174 M/sec                    ( +-  0.04% )  (85.66%)
                17      branch-misses:u           #    0.00% of all branches          ( +- 52.94% )  (85.78%)
     4,012,165,560      uops_issued.any:u         # 3279.113 M/sec                    ( +-  0.03% )  (85.78%)
     4,010,429,819      uops_executed.thread:u    # 3277.694 M/sec                    ( +-  0.01% )  (85.78%)
        28,452,608      cpu_clk_thread_unhalted.one_thread_active:u #   23.254 M/sec                    ( +-  0.20% )  (57.01%)

           1.22396 +- 0.00660 seconds time elapsed  ( +-  0.54% )

（计数器cpu_clk_thread_unhalted.one_thread_active:u仅以较慢的速度计数；系统在此测试期间相当空闲，因此它应该一直拥有核心。即〜23.2 M 计数/秒确实代表单线程模式。）

与一起运行的 0 和接近 0 计数相比，我成功地让这些任务在同一个核心上同时运行，使用超线程，基本上整个时间（~1.2 秒重复两次，或 2.4 秒）。

因此，每个 RDTSC 单线程 5.0038G 周期 / 10M iters / 20 rdtsc/iter = 25.019 个周期，这与 Agner Fog 测量的差不多。

对 HT 测试的两个过程进行平均，平均约为 5.244G 周期 / 10M iter / 20 rdtsc/iter = 26.22 个周期。

因此，在 Skylake 上同时在两个逻辑核心上运行 RDTSC 可以提供几乎线性的加速，并且对吞吐量资源的竞争非常小。 无论 RDTSC 瓶颈是什么，这不是两个线程相互竞争或减慢彼此速度的东西。

让另一个核心忙于运行高吞吐量代码（如果它自己有一个核心，则每个时钟可以维持 4 微秒）可能会比另一个也只运行 RDTSC的线程更伤害 RDTSC 线程。也许我们甚至可以弄清楚RDTSC 是否比其他端口更需要一个特定的端口，例如端口1 很容易饱和，因为它是唯一可以运行整数乘法指​​令的端口。

于 2019-06-04T08:41:42.807 回答