时间戳

首页 > 解决方案 > resource_stall.other 可能意味着什么

performance - resource_stall.other 可能意味着什么

问题描述

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 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

新台币商店：

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

标签： performanceassemblyx86x86-64

解决方案

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

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

计数与资源相关的停顿周期。停顿的原因如下
：任何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变得可以忽略不计。

推荐阅读