C代码循环的性能
这个问题在这里继续我的问题（根据神秘的build议）：
C代码循环的性能
继续我的问题，当我使用打包指令，而不是标量指令使用内在函数的代码看起来非常相似：
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); } 这个内核的testing性能是每个周期大约5.6个FP操作，但是我认为它恰好是标量版本的4倍，即4.1,6 = 6,4个FP操作每个周期。
考虑到重量因素的移动（感谢指出），时间表看起来像：
它看起来像日程安排不会改变，虽然在movss操作之后有一个额外的指令，将标量权值移到XMM寄存器，然后使用shufps在整个vector中复制这个标量值。 考虑到从负载到浮点域的切换延迟时间，似乎权重vector已经准备好用于mulps ，所以这不应该引起任何额外的延迟。
在这个内核中使用的movaps （alignment的，压缩的移动）， addps ＆ mulps指令（用汇编代码检查）与标量版本具有相同的延迟和吞吐量，所以这不应该引起任何额外的延迟。
假设这个内核可以获得的最高性能是每个周期6.4 FP运算，并且每个周期运行在5.6 FP运算？
顺便说一下，这里是实际组装的样子：
… 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> …
尝试在Vtune中使用EMON分析，或者使用一些类似oprof的工具
- Vtune for Linux （可以searchWindows版本）
- oprofile的
EMON（事件监测）分析=>就像一个基于时间的工具，但它可以告诉你什么性能事件造成的问题。 虽然，您应该先从基于时间的configuration文件开始，看看是否有特定的指令跳出。 （可能有相关的事件告诉你这个知识产权里有一个退休档。
要使用EMON分析，您必须运行一系列事件，从“常见的嫌疑人”到…
在这里，我将从caching未命中开始。 我不知道你使用的处理器是否有RF端口限制的计数器 – 它应该 – 但是我之前加了EMON分析，而且我不知道如何通过添加适合于微体系结构的事件来保持它们。
它也可能是一个前端，取指令，失速。 无论如何，这些指令中有多less个字节？ 也有EMON事件。
回应评论说，Nehalem VTune不能看到L3事件：不正确。 这里是我join评论的东西，但不适合：
实际上，有LL3 / L3 $ /所谓Uncore的性能计数器。 如果VTune不支持他们，我会非常惊讶。 请参阅http://software.intel.com/sites/products/collateral/hpc/vtune/performance_analysis_guide.pdf指向VTune和其他工具（如PTU）。; 事实上，即使没有LL3事件，正如David Levinthal所说：“英特尔®酷睿™i7处理器有一个与”安腾®处理器系列数据EAR事件“非常相似的”延迟事件“。在执行指令和实际传送数据之间的周期，如果测量的延时大于MSR 0x3f6中设置的最小延时（位15：0），则计数器递增计数器溢出支持PEBS机制，事件满足等待时间阈值，测量的等待时间，虚拟或线性地址和数据源被复制到PEBS缓冲区中的3个附加寄存器中，因为虚拟地址被捕获到已知位置，所以采样驱动器也可以执行虚拟到物理翻译和捕获物理地址，物理地址标识NUMA归属位置，原则上允许分析caching占用的细节。 他还指出了第35页的VTune事件，例如L3 CACHE_HIT_UNCORE_HIT和L3 CACHE_MISS_REMOTE_DRAM。 有时你需要查看数字代码并将它们编程到VTune的较低级别的界面中，但我认为在这种情况下，它可以在美观的用户界面中看到。
他错了 – 例如，你可以只启用一个CPU，然后进行有意义的采样。 我也相信，当它返回到CPU时，有能力标记L3丢失的数据。 实际上，L3总体上知道哪个CPU正在返回数据，所以你绝对可以抽样。 你可能不知道哪个超线程，但是你可以禁用，进入单线程模式。
但是看起来像是相当普遍的，你必须在VTune周围工作，而不是在VTune上工作。
先尝试延迟分析。 这完全在CPU内部，而VTune的人们不太可能把它搞乱。
而且，我再说一遍，可能性是你的问题在核心，而不是L3。 所以VTune应该能够处理这个问题。
尝试每个Levinthal“循环会计”。
