C 代码循环性能 [续]

Question

这个问题在我这里的问题上继续(根据 Mystical 的建议):

C code loop performance

---

继续我的问题，当我使用打包指令而不是标量指令时，使用内部函数的代码看起来非常相似:

for(int i=0; i<size; i+=16) {
    y1 = _mm_load_ps(output[i]);
    …
    y4 = _mm_load_ps(output[i+12]);

    for(k=0; k<ksize; k++){
        for(l=0; l<ksize; l++){
            w  = _mm_set_ps1(weight[i+k+l]);

            x1 = _mm_load_ps(input[i+k+l]);
            y1 = _mm_add_ps(y1,_mm_mul_ps(w,x1));
            …
            x4 = _mm_load_ps(input[i+k+l+12]);
            y4 = _mm_add_ps(y4,_mm_mul_ps(w,x4));
        }
    }
    _mm_store_ps(&output[i],y1);
    …
    _mm_store_ps(&output[i+12],y4);
    }

该内核的测量性能约为每个周期 5.6 FP 操作，但我预计它正好是标量版本性能的 4 倍，即每个周期 4.1,6=6,4 FP 操作。

考虑到权重因子的移动(感谢您指出这一点)，时间表如下:

看起来时间表没有改变，虽然在 movss 操作之后有一条额外的指令将标量权重值移动到 XMM 寄存器，然后使用 shufps 在整个 vector 中复制这个标量值。考虑到从负载到浮点域的切换延迟，权重 vector 似乎已准备好及时用于 mulps，因此这不应产生任何额外延迟。

此内核中使用的movaps(对齐、打包移动)、addps 和mulps 指令(使用汇编代码检查)具有与其标量版本相同的延迟和吞吐量，因此这也不应产生任何额外的延迟。

是否有人知道每 8 个周期的这个额外周期花在了哪里，假设这个内核可以获得的最大性能是每个周期 6.4 FP 操作并且它以每个周期 5.6 FP 操作运行？

---

顺便说一句，实际的 assembly 是这样的:

…
Block x: 
  movapsx  (%rax,%rcx,4), %xmm0
  movapsx  0x10(%rax,%rcx,4), %xmm1
  movapsx  0x20(%rax,%rcx,4), %xmm2
  movapsx  0x30(%rax,%rcx,4), %xmm3
  movssl  (%rdx,%rcx,4), %xmm4
  inc %rcx
  shufps $0x0, %xmm4, %xmm4               {fill weight vector}
  cmp $0x32, %rcx 
  mulps %xmm4, %xmm0 
  mulps %xmm4, %xmm1
  mulps %xmm4, %xmm2 
  mulps %xmm3, %xmm4
  addps %xmm0, %xmm5 
  addps %xmm1, %xmm6 
  addps %xmm2, %xmm7 
  addps %xmm4, %xmm8 
  jl 0x401ad6 <Block x> 
…

Answer 1

尝试在 Vtune 中使用 EMON 分析，或使用类似 oprof 的等效工具

• Vtune for Linux (您可以搜索Windows版本)
• oprofile

EMON(事件监控)分析 => 就像一个基于时间的工具，但它可以告诉您是什么性能事件导致了问题。虽然，您应该先从基于时间的配置文件开始，看看是否有特定的指令跳出。 (可能还有相关事件告诉您该 IP 的退休摊位的频率。)

要使用 EMON 分析，您必须遍历一系列事件，从“通常的嫌疑人”到......

在这里，我将从缓存未命中、对齐开始。我不知道您使用的处理器是否有 RF 端口限制的计数器 - 它应该 - 但我很久以前就添加了 EMON 分析，而且我不知道它们通过添加适合微体系结构的事件来跟上的情况如何。

也有可能是前端，取指，stall。无论如何，这些指令中有多少字节？也有 EMON 事件。

---

回应评论说 Nehalem VTune 看不到 L3 事件:不正确。这是我添加到评论中但不适合的内容:

实际上，有针对 LL3/L3$/所谓的 Uncore 的性能计数器。如果 VTune 不支持它们，我会感到非常惊讶。参见 http://software.intel.com/sites/products/collateral/hpc/vtune/performance_analysis_guide.pdf指向 VTune 和其他工具，例如 PTU。事实上，即使没有 LL3 事件，正如 David Levinthal 所说:“英特尔® 酷睿™ i7 处理器有一个‘延迟事件’，它是与 Itanium® 处理器系列数据 EAR 事件非常相似。本次事件 sample 负载，记录指令执行和实际之间的周期数数据的传递。如果测量的延迟大于最小延迟编程到 MSR 0x3f6，位 15:0，然后计数器递增。柜台溢出激活 PEBS 机制，并在下一个满足延迟的事件上阈值、测量的延迟、虚拟或线性地址和数据源是复制到 PEBS 缓冲区中的 3 个附加寄存器中。因为虚拟地址是捕获到一个已知位置，采样驱动程序还可以执行一个虚拟到物理翻译并捕获物理地址。物理地址标识NUMA 主页位置和原则上允许分析缓存的详细信息占用。”他还在第 35 页指出 VTune 事件，例如 L3 CACHE_HIT_UNCORE_HIT 和 L3 CACHE_MISS_REMOTE_DRAM。有时您需要查找数字代码并将它们编程到 VTune 的较低级别接口(interface)中，但我认为在这种情况下它是可见的漂亮的用户界面。

---

好的，在http://software.intel.com/en-us/forums/showthread.php?t=77700&o=d&s=lr俄罗斯的一位 VTune 程序员(我认为)“解释”说您不能对 Uncore 事件进行采样。

他错了——例如，您可以只启用一个 CPU，并进行有意义的采样。我还相信，在返回 CPU 时可以标记 L3 丢失的数据。事实上，总的来说，L3 知道它正在向哪个 CPU 返回数据，所以你绝对可以采样。您可能不知道哪个超线程，但您可以再次禁用，进入单线程模式。

但看起来，这很常见，您必须围绕 VTune 工作，而不是使用它来执行此操作。

首先尝试延迟分析。这完全在 CPU 内部，VTune 人员不太可能把它搞得一团糟。

而且，我再说一遍，您的问题很可能在核心，而不是在 L3。所以 VTune 应该能够处理这个问题。

---

试试 Levinthal 的“周期会计”。