C代码循环性能[续]

时间:2012-04-04 08:11:33

标签: c performance intel instructions assembly

这个问题在我的问题上继续存在(根据神秘的建议):

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

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

schedule

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

movaps(对齐,打包移动),addps&amp;此内核中使用的mulps指令(使用汇编代码检查)具有相同的延迟和时间。吞吐量作为它们的标量版本,所以这不应该产生任何额外的延迟。

是否有人知道每8个周期的额外周期花费在哪里,假设这个内核可以获得的最大性能是每个周期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> 
…

1 个答案:

答案 0 :(得分:3)

尝试在Vtune中使用EMON分析,或者像oprof

这样的等效工具

EMON(事件监控)分析=&gt;像基于时间的工具,但它可以告诉你导致问题的性能事件。虽然,您应该首先使用基于时间的配置文件,以查看是否有跳出的特定指令。 (可能还有相关的事件告诉你在那个IP上经常有一个退休摊位。)

要使用EMON分析,您必须运行一系列事件,范围从“通常的嫌疑人”到......

在这里,我将从缓存未命中,对齐开始。我不知道你使用的处理器是否有一个RF端口限制的计数器 - 它应该 - 但我很久以前就加入了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事件,正如David Levinthal所说:“英特尔®酷睿™i7处理器有一个”延迟事件“,这是 与Itanium®处理器系列数据EAR事件非常相似。此事件样本 加载,记录执行指令和实际之间的循环次数 提供数据。如果测量的延迟大于最小延迟 编程到MSR 0x3f6,位15:0,然后计数器递增。计数器 溢出武装PEBS机制和下一个满足延迟的事件 阈值,测量的延迟,虚拟或线性地址和数据源 复制到PEBS缓冲区中的3个附加寄存器。因为虚拟地址是 捕获到已知位置,采样驱动程序也可以执行虚拟到 物理翻译和捕获物理地址。物理地址标识 NUMA家庭位置原则上允许分析缓存的细节 在第35页,他还指出了L3 CACHE_HIT_UNCORE_HIT和L3 CACHE_MISS_REMOTE_DRAM等VTune事件。有时您需要查找数字代码并将它们编程到VTune的低级接口中,但我认为在这种情况下它是可见的漂亮的用户界面。


好的,在http://software.intel.com/en-us/forums/showthread.php?t=77700&o=d&s=lr俄罗斯的VTune程序员(我认为)“解释”你无法在Uncore活动中进行采样。

他错了 - 例如,你可以只启用一个CPU,并进行有意义的采样。我也相信能够在返回CPU时标记L3缺失数据。事实上,整体而言L3知道它将数据返回到哪个CPU,所以你绝对可以采样。你可能不知道哪个超线程,但你可以再次禁用,进入单线程模式。

但看起来,相当常见的是,你必须工作AROUND VTune而不是它,才能做到这一点。

首先尝试延迟分析。这完全在CPU内部,而VTune人员不太可能把它弄得太乱。

而且,我再说一遍,可能是你的问题是核心,而不是L3。所以VTune应该能够处理它。


根据Levinthal尝试“循环会计”。