resource_stall.other 可能意味着什么

Question

Whiskey Lake i7-8565U

RESOURCE_STALLS.OTHER 看起来不像英特尔文档中解释的那样：

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

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

---

基线：

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 Stores 柜台：

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 Stores 柜台：

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，所以我很想知道在 Skylake 或更高版本上分析内存绑定例程时 RESOURCE_STALLS.OTHER 可能意味着什么。

Answer 1

英特尔仅记录了您的处理器上与资源相关的两个停顿，即RESOURCE_STALLS.ANY 和RESOURCE_STALLS.SB。其他事件记录在 Nehalem/Westmere 上，但这并不意味着它们将在 Skylake 上准确运行。您必须先验证它们，然后再尝试理解事件计数。至少，我们必须检查RESOURCE_STALLS.ANY 是否等于RESOURCE_STALLS.SB 和其他未记录事件的总和。看起来他们确实加起来了。 （IIRC，大约两年前，我不得不在 Haswell 上验证其中一些未记录的事件，但不幸的是，我现在不记得是哪些事件了。）

英特尔手册对 Skylake 上的RESOURCE_STALLS.ANY 描述如下：

Countsresource-related 停顿周期。停顿的原因可以是 如下：
一种。 任何 u-arch 结构已满（LB、SB、RS、ROB、BOB、LM、 物理寄存器回收表 (PRRT)，或 物理历史表 (PHT) 插槽）。
湾。 任何 u-arch 结构为空（如 INT/SIMD FreeLists）。
C。 FPU控制字（FPCW）、MXCSR.等。
这计算周期 管道后端阻止了来自前端的 uop 传递。

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

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

以下是适用于所有无序微架构的每个类别的简要说明：

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

您调用RESOURCE_STALLS.OTHER 的事件包括以下类别：BOB、LM、PRRT、PHT、空闲列表等。我认为你在拖延LM。尝试将负载更改为写入相同目标寄存器的非内存指令，看看RESOURCE_STALLS.OTHER 是否变得可以忽略不计。