C代码循环性能[续]

C code loop performance [continued]

这个问题在这里继续我的问题(根据神秘主义的建议)：

C代码循环性能

继续我的问题，当我使用压缩指令而不是标量指令时，使用intrinsics的代码看起来非常相似：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

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操作。

考虑到重量因素的变化(感谢您指出)，日程安排如下：

schedule

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

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

有人知道每8个周期的额外周期是在什么地方花费的吗，假设这个内核可以获得的最大性能是每周期6.4 fp ops，并且它以每周期5.6 fp ops的速度运行？

顺便说一下，实际的装配是这样的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

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

相关讨论

所以我想现在的问题是："为什么shufps指令每1.6次迭代就增加1个周期？"这是一个困难的…
我希望它没有开销，因为shufps的输出应该直接提供给multpsop，因为它都是fp域。
很容易找到。确保权重向量不包含任何非规范化的值。尝试不使用shuffle指令的循环。它不会产生任何有用的结果，但也许您会发现哪个指令会花费您额外的周期(当然，我怀疑是无序排列)。
@神秘：我看到每个循环增加0.75个循环。(不是我对使用5个周期而不是4个周期的评论导致了你在那里的答案……-)
@赫希博士当然每个人都害怕非标准化的值…另一个尝试是用具有相同值的simd块替换权重向量。这样你就可以做正常的负荷，而不需要洗牌。
@Danleakin如果你把实际的循环计数作为测量值，而不是基本上无用的触发器/循环值，而不是让我们推断出来，这将是很有帮助的。
@是的，你的评论确实给了我正确的方向。：)不过，这个更难……很难怀疑任何特别的事情。现代的CPU有太多的功能。P
@神秘的事实上，你给出的答案是我的第一个想法。5个负载-5个循环-很容易看到巧合。但后来我记得我现在的sb可以每循环加载2次，忽略了这个问题是关于一个nehalem的事实，所以我决定这可能是答案：—)
@赫希博士，是的，我也犹豫了，因为我认为标量负载可能是尼哈伦的多个问题。很明显，当我看阿格纳的桌子时，我错了。Nehalem无法按照sb将其256位/周期拆分为双问题SSE负载的方式拆分其128位/周期负载带宽。
好吧，我试着用load指令删除shufps，但性能没有提高，我认为这意味着shufps不是这里的坏人。还有其他解释吗？可能打包的movaps指令有一些额外的缓存延迟(未命中、未对齐)，而标量版本中的movss指令没有这种延迟？
首先，现在您需要4倍的缓存带宽。数据大小有多大？它们是否适合一级缓存？
是的，数据适合一级缓存
@Danleakin你能把负载从循环中移出，然后完全移除SHUFP吗？所以基本上你有相同的代码，但是每一个标量指令都被一个向量指令取代了？
当把load移出循环，从而在每次迭代中删除shufps指令时，性能几乎保持不变(因为一个负载消失，所以会稍微提高一点)，因此我假设它是由缓存引起的。
这不完全是你问题的答案，但你不能使用dpp吗？
您使用的是FTZ(齐平到零)和DAZ模式吗？
我不使用FTZ或DAZ。@Necrolis谢谢你的链接，我查一下
如果可能的话，我将使用Intel Inspector(或其前身"vtune性能分析器")查看性能究竟在哪里停止。
我已经使用vtune分析了代码，但这并不能让我对周期级别的性能瓶颈有更多的了解。
你有什么样的数据我们可以自己测试吗？(或生成类似数据的简单方法。)
当然，只要在for循环前面有一个循环初始化一些值，比如for(i=0;i<2*size;i++) input[i] = i/3; output[i] = i/5; weight[i] = i/8;，并保持ksize在循环中处于低位(mine是6)。

尝试在"vtune"中使用emon评测，或类似oprof的工具。

vtune for Linux(可以搜索Windows版本)
奥普罗菲尔

emon(事件监视)分析=>类似于基于时间的工具，但它可以告诉您是什么性能事件导致了问题。不过，您应该首先从一个基于时间的概要文件开始，看看是否有一个特定的指令会跳出来。(也可能是相关事件，告诉您在该IP上多久会有一个退休摊位。)

要使用emon分析，您必须运行一系列事件，从"常见的嫌疑犯"到…

在这里，我将从缓存未命中、对齐开始。我不知道您使用的处理器是否有一个射频端口限制的计数器——它应该——但是我很久以前就添加了emon分析，我不知道通过添加适合微体系结构的事件，它们能保持多久。

它也可能是前端、指令获取、暂停。无论如何，这些指令中有多少字节？也有一些emon事件。

回应Nehalem vtune看不到L3事件的评论：不是真的。以下是我添加到评论中但不适合的内容：

实际上，有LL3/L3$的性能计数器，也就是所谓的UNCORE。如果vtune不支持它们，我会非常惊讶。请参阅http://software.intel.com/sites/products/collateral/hpc/vtune/performance_analysis_guide.pdf指向vtune和其他工具，如ptu。事实上，即使没有ll3事件，正如大卫·莱文塔尔所说："英特尔？核心？I7处理器有一个"延迟事件"，即很像Itanium？处理器系列数据EAR事件。此事件示例加载，记录指令执行和实际执行之间的循环数交付数据。如果测量的延迟大于最小延迟编程到MSR 0x3F6，位15:0，然后计数器递增。计数器溢出将启用PEBS机制，并在满足延迟的下一个事件上启用阈值、测量的延迟、虚拟或线性地址和数据源复制到pebs缓冲区的3个附加寄存器中。因为虚拟地址是捕获到已知位置后，采样驱动程序还可以执行虚拟到物理翻译和捕获物理地址。物理地址标识numa主位置和原则上允许分析缓存的详细信息他还指出，在第35页，vtune事件，如l3缓存命中uncore缓存命中和l3缓存命中远程dram。有时您需要查找数字代码并将其编程到vtune的低级界面中，但我认为在这种情况下，它在漂亮的用户界面中是可见的。

好的，在http://software.intel.com/en-us/forums/showthread.php中？t=77700&o=d&s=lr俄罗斯的一个vtune程序员(我想)"解释"你不能对uncore事件进行采样。

他错了-例如，您可以只启用一个CPU，并有意义地进行采样。我还相信，当L3返回CPU时，它能够标记丢失的数据。事实上，总的来说，L3知道它将数据返回到哪个CPU，所以您肯定可以进行采样。您可能不知道哪个超线程，但是您可以再次禁用，进入单线程模式。

但看起来，很常见的是，要做到这一点，您必须围绕"vtune"工作，而不是使用它。

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

我再说一遍，很可能你的问题是核心问题，而不是L3。因此，vtune应该能够处理这个问题。

尝试"循环会计"每列文塔尔。