resource_stall.other 可能意味着什么

Question

Whiskey Lake i7-8565U

\n\n

RESOURCE_STALLS.OTHER英特尔文档看起来并没有很好地解释：

\n\n

\n

计算由于其他资源问题而导致执行停滞的周期数。\n

\n

\n\n

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

\n\n

---

\n\n

基线：

\n\n

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

\n\n

基线计数器：

\n\n

   823\xe2\x80\xaf292\xe2\x80\xaf269      resource_stalls.any\n       181\xe2\x80\xaf045      r02a2 #LOAD\n   831\xe2\x80\xaf370\xe2\x80\xaf403      r04a2 #RS_FULL\n        49\xe2\x80\xaf659      resource_stalls.sb\n       130\xe2\x80\xaf100      r10a2 #ROB_FULL\n        63\xe2\x80\xaf386      r20a2 #FPCW\n     2\xe2\x80\xaf151\xe2\x80\xaf516      r40a2 #MSCXR\n         4\xe2\x80\xaf222      r80a2 #OTHER  \n

\n\n

世界银行商店：

\n\n

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

\n\n

WB专卖店柜台：

\n\n

27\xe2\x80\xaf089\xe2\x80\xaf245\xe2\x80\xaf473      resource_stalls.any\n     4\xe2\x80\xaf873\xe2\x80\xaf836      r02a2  #LOAD                                                                                                                                          \n    14\xe2\x80\xaf099\xe2\x80\xaf696      r04a2  #RS_FULL                                                                                                                                          \n24\xe2\x80\xaf130\xe2\x80\xaf341\xe2\x80\xaf296      resource_stalls.sb                                                                                                                                                               \n     5\xe2\x80\xaf790\xe2\x80\xaf969      r10a2  #ROB_FULL                                                                                                                                               \n       375\xe2\x80\xaf032     r20a2   #FPCW                                                                                                                                                      \n     3\xe2\x80\xaf395\xe2\x80\xaf592      r40a2  #MXCSR\n 4\xe2\x80\xaf899\xe2\x80\xaf892\xe2\x80\xaf032      r80a2   #resource_stalls.other 14% of RESOURCE_STALL.ANY\n

\n\n

北领地商店：

\n\n

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

\n\n

NT专卖店柜台：

\n\n

18\xe2\x80\xaf121\xe2\x80\xaf917\xe2\x80\xaf993      resource_stalls.any\n     2\xe2\x80\xaf211\xe2\x80\xaf195      r02a2 #LOAD\n     5\xe2\x80\xaf588\xe2\x80\xaf784      r04a2 #RS_FULL\n12\xe2\x80\xaf061\xe2\x80\xaf475\xe2\x80\xaf989      resource_stalls.sb\n     3\xe2\x80\xaf156\xe2\x80\xaf129      r10a2 #ROB_FULL\n       165\xe2\x80\xaf967     r20a2  #FPCW\n     2\xe2\x80\xaf152\xe2\x80\xaf595      r40a2  #MXCSR                                                       \n 6\xe2\x80\xaf730\xe2\x80\xaf668\xe2\x80\xaf837      r80a2 #resource_stalls.other 33% of RESOURCE_STALLS.ANY   \n

\n\n

---

\n\n

在非临时存储的情况下，这一点非常明显，它占用了所有资源停顿的 1/3，因此我很想知道RESOURCE_STALLS.OTHER在 Skylake 或更高版本上分析内存绑定例程时这可能意味着什么。

\n

Answer 1

英特尔仅记录了处理器上两个与资源相关的停顿，即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) 插槽）。
b. 任何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的目的地）。当有太多 uop 依赖于少量负载时，LM 可能会先于 LB 变满。如果依赖较少但负载过多，则 LB 可能会先满。
• PRRT：每次修改物理寄存器的微指令退出时，物理寄存器回收表都会更新，以指定用于映射同一架构寄存器的旧版本的物理寄存器现在可以被回收（因为现在有一个新的映射）对于该寄存器）。该结构跟踪分配的物理寄存器。如果分配器需要分配物理寄存器，则 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变得可以忽略不计。