Question

Whiskey Lake i7-8565U

RESOURCE_STALLS.OTHER看起来不像是英特尔文档的很好解释：

计算由于其他原因导致执行停止的周期数资源问题。

我在16MiB个迭代组成的循环中，对6400随机生成的数据的内存副本示例进行了实验。

基线：

avx_memcpy_baseline:
    shr rdx, 0x3
    xor rcx, rcx
avx_memcpy_baseline_loop:
    add rcx, 0x08
    cmp rdx, rcx
    ja avx_memcpy_baseline_loop
    ret

基准计数器：

   823 292 269      resource_stalls.any
       181 045      r02a2 #LOAD
   831 370 403      r04a2 #RS_FULL
        49 659      resource_stalls.sb
       130 100      r10a2 #ROB_FULL
        63 386      r20a2 #FPCW
     2 151 516      r40a2 #MSCXR
         4 222      r80a2 #OTHER

WB商店：

avx_memcpy_forward_llss:
    shr rdx, 0x3
    xor rcx, rcx
avx_memcpy_forward_loop_llss:
    vmovdqa ymm0, [rsi + 8*rcx]
    vmovdqa ymm1, [rsi + 8*rcx + 0x20]
    vmovdqa [rdi + rcx*8], ymm0
    vmovdqa [rdi + rcx*8 + 0x20], ymm1
    add rcx, 0x08
    cmp rdx, rcx
    ja avx_memcpy_forward_loop_llss
    ret

WB存储计数器：

27 089 245 473      resource_stalls.any
     4 873 836      r02a2  #LOAD                                                                                                                                          
    14 099 696      r04a2  #RS_FULL                                                                                                                                          
24 130 341 296      resource_stalls.sb                                                                                                                                                               
     5 790 969      r10a2  #ROB_FULL                                                                                                                                               
       375 032     r20a2   #FPCW                                                                                                                                                      
     3 395 592      r40a2  #MXCSR
 4 899 892 032      r80a2   #resource_stalls.other 14% of RESOURCE_STALL.ANY

NT商店：

avx_nt_memcpy_forward_llss:
    shr rdx, 0x3
    xor rcx, rcx
avx_nt_memcpy_forward_loop_llss:
    vmovdqa ymm0, [rsi + 8*rcx]
    vmovdqa ymm1, [rsi + 8*rcx + 0x20]
    vmovntdq [rdi + rcx*8], ymm0
    vmovntdq [rdi + rcx*8 + 0x20], ymm1
    add rcx, 0x08
    cmp rdx, rcx
    ja avx_nt_memcpy_forward_loop_llss
    ret

NT商店柜台：

18 121 917 993      resource_stalls.any
     2 211 195      r02a2 #LOAD
     5 588 784      r04a2 #RS_FULL
12 061 475 989      resource_stalls.sb
     3 156 129      r10a2 #ROB_FULL
       165 967     r20a2  #FPCW
     2 152 595      r40a2  #MXCSR                                                       
 6 730 668 837      r80a2 #resource_stalls.other 33% of RESOURCE_STALLS.ANY

在非临时性商店中，它占用了所有资源停顿的1/3，这是非常值得注意的，因此，我很想知道RESOURCE_STALLS.OTHER在Skylake或更高版本上对内存绑定例程进行概要分析时可能意味着什么。 / p>

Answer 1

英特尔仅在您的处理器上记录了两个与资源相关的停顿，即RESOURCE_STALLS.ANY和RESOURCE_STALLS.SB。其他事件已记录在Nehalem / Westmere上，但这并不意味着它们可以在Skylake上正常工作。您必须先对它们进行验证，然后才能从事件计数中弄清楚。至少，我们必须检查RESOURCE_STALLS.ANY是否等于RESOURCE_STALLS.SB与其他未记录事件的总和。看起来他们确实加起来了。（IIRC，大约两年前，我处于不得不验证Haswell上某些未记录事件的情况，但不幸的是，现在我不记得是哪个事件。）

Intel手册在Skylake上对RESOURCE_STALLS.ANY的描述如下：

计算与资源相关的停顿周期。停顿原因可以是如下：
一种。 any u-arch结构已满（LB，SB，RS，ROB，BOB，LM，物理寄存器回收表（PRRT），或物理历史记录表（PHT）插槽）。
b。 any 的u-arch结构为空（如INT / SIMD FreeLists）。
C。 FPU控制字（FPCW），MXCSR等。
计数周期管道后端阻止了前端的uop交付。

此描述提供了与资源相关的停顿的类别的部分列表，而不是特定的停顿原因。例如，RS类别包括许多特定于RS的停顿原因。这些问题存在于英特尔大多数乱序的微体系结构中，但是具体的停顿原因在不同的微体系结构中可能有很大的不同。就其对性能的影响而言，每个类别的相对重要性也取决于微体系结构。从分析的角度来看，这种分类很方便。

请注意，现在在RESOURCE_STALLS.ANY下简单地提到了在旧的微体系结构上记录性能事件的许多停顿原因，这意味着即使没有记录相应的事件，它们仍然存在。

以下是适用于所有乱序微体系结构的以下每个类别的简要说明：

LB：负载缓冲区保存负载uops和在负载管道上执行的其他uops。此类别包括特定于LB的停转原因。当分配器由于任何原因无法分配LB条目时，就会发生LB停顿。
SB：存储缓冲区保存在存储管道上执行的STA，STD和其他块。此类别包括特定于SB的停转原因。如果分配器由于某种原因无法分配SB条目，则会发生SB停顿。
RS：这包含所有未完成的uops。 RS可以是分布式的，也可以是统一的，具体取决于微体系结构。在这两种设计中，与RS相关的档位都属于此类。
ROB：这将保留所有uops以便按程序顺序将其退役。
BOB：分支顺序缓冲区将寄存器状态与每个推测的分支（条件分支或间接分支）相关联，以实现快速的错误预测恢复。
LM：加载矩阵跟踪RS中任何uop与RS中所有加载uop之间的寄存器依赖关系（即，一个uop将物理寄存器作为输入，该物理寄存器是按程序顺序位于前面的加载uop的目的地）。当过多的uops取决于少量负载时，LM可能会在LB之前变满。如果依赖项很少但负载过多，则LB可能会先变满。
PRRT：每次修改物理寄存器的uop退出时，物理寄存器回收表都会更新，以指定用于映射相同体系结构寄存器旧版本的物理寄存器现在可以被回收（因为现在有该寄存器的新映射）。该结构跟踪分配的物理寄存器。如果分配器要求分配物理寄存器，则PRRT中必须有一个空闲条目。否则，它将停止。
PHT：这跟踪每个体系结构寄存器到一个或多个物理寄存器的所有当前映射。此结构用于支持快速的分支恢复。
INT和SIMD空闲列表：有一些逻辑可以根据PRRT的信息回收寄存器。回收物理寄存器后，会将其添加到称为“空闲列表”的结构中，该结构有效地释放了分配空间。有两个可用列表，一个用于GP寄存器，另一个用于SIMD寄存器。分配器使用这些列表来了解哪些寄存器是空闲的。与物理寄存器的可用性有关的停顿属于此类。
FPCW：写入浮点控制字的指令，例如FLDCW，可能会使流水线停滞，直到所有较早的指令完成执行。条件取决于修改的微体系结构和FPCW位（请参阅英特尔优化手册的3.8.3节）。这些摊位在这里计算。
MXCSR：这类似于FLDCW。写入MXCSR寄存器的指令，例如LDMXCSR，可能会使流水线停滞，直到所有较早的指令完成执行。一个微体系结构可以重命名MXCSR，但是，如果不这样，则它必须在更改舍入模式之前完成较旧的数学指令。
其他：还有许多其他停滞原因，这些都不属于先前的类别。英特尔已决定不提及它们。

您称为RESOURCE_STALLS.OTHER的事件包括以下类别：BOB，LM，PRRT，PHT，空闲列表等。我认为您正在停滞不前。尝试将负载更改为写入相同目标寄存器的非内存指令，并查看RESOURCE_STALLS.OTHER是否可以忽略。

resource_stall.other可能意味着什么

1 个答案: