为什么asm的这种差异对性能有影响(在未优化的ptr ++与++ ptr循环中)?

fja*_*sze 15 c++ performance x86 assembly loops

TL; DR:第一个循环在Haswell CPU上运行速度快〜18%.为什么?循环来自gcc -O0使用ptr++vs的(未优化的)循环++ptr,但问题是为什么生成的asm表现不同,而不是关于如何写出更好的C.


假设我们有两个循环:

    movl    $0, -48(%ebp)     //Loop counter set to 0
    movl    $_data, -12(%ebp) //Pointer to the data array
    movl    %eax, -96(%ebp)
    movl    %edx, -92(%ebp)
    jmp L21
L22:
    // ptr++
    movl    -12(%ebp), %eax   //Get the current address
    leal    4(%eax), %edx     //Calculate the next address
    movl    %edx, -12(%ebp)   //Store the new (next) address
    // rest of the loop is the same as the other
    movl    -48(%ebp), %edx   //Get the loop counter to edx
    movl    %edx, (%eax)      //Move the loop counter value to the CURRENT address, note -12(%ebp) contains already the next one
    addl    $1, -48(%ebp)     //Increase the counter
L21:
    cmpl    $999999, -48(%ebp)
    jle     L22
Run Code Online (Sandbox Code Playgroud)

第二个:

    movl    %eax, -104(%ebp)
    movl    %edx, -100(%ebp)
    movl    $_data-4, -12(%ebp) //Address of the data - 1 element (4 byte)
    movl    $0, -48(%ebp)       //Set the loop counter to 0
    jmp L23
L24:
    // ++ptr
    addl    $4, -12(%ebp)       //Calculate the CURRENT address by adding one sizeof(int)==4 bytes
    movl    -12(%ebp), %eax     //Store in eax the address
    // rest of the loop is the same as the other
    movl    -48(%ebp), %edx     //Store in edx the current loop counter
    movl    %edx, (%eax)        //Move the loop counter value to the current stored address location
    addl    $1, -48(%ebp)       //Increase the loop counter
L23:
    cmpl    $999999, -48(%ebp)
    jle L24
Run Code Online (Sandbox Code Playgroud)

这些循环完全相同,但以不同的方式,请参阅注释的详细信息.

这个asm代码是从以下两个C++循环生成的:

    //FIRST LOOP:
    for(;index<size;index++){
        *(ptr++) = index;
    }
    //SECOND LOOP:
    ptr = data - 1;
    for(index = 0;index<size;index++){
        *(++ptr) = index;
    }
Run Code Online (Sandbox Code Playgroud)

现在,第一个循环比第二个循环快约18%,无论循环执行的顺序是哪个循环ptr++都快于具有循环的循环++ptr.

为了运行我的基准测试,我只收集了不同大小的循环的运行时间,并将它们嵌套在其他循环中以经常重复操作.


ASM分析

查看ASM代码,第二个循环包含较少的指令,我们有3个movl和2个addl,而在第一个循环中我们有4个movl,一个addl和一个leal,所以我们有一个movl和一个leal而不是addl

是否正确LEA计算正确地址的操作比ADD(+4)方法快得多?这是性能差异的原因吗?

据我所知,一旦在内存被引用之前计算了一个新地址,必须经过一些时钟周期,所以addl $ 4之后的第二个循环,-12(%ebp)需要等待一小段才能继续,而在第一个循环我们可以立即引用内存,同时LEAL将计算下一个地址(这里有一些更好的流水线性能).

这里有一些重新排序吗?我不确定我对这些循环的性能差异的解释,我可以有你的意见吗?

Pet*_*des 13

首先,-O0编译器输出的性能分析通常不是很有趣或有用.


用于计算正确地址的LEAL操作比ADDL(+4)方法快得多是否正确?这是性能差异的原因吗?

不,add可以在任何x86 CPU上的每个ALU执行端口上运行. lea通常具有简单寻址模式的低延迟,但吞吐量不高.在Atom上,它在正常ALU指令的管道的不同阶段运行,因为它实际上符合其名称并在有序微体系结构上使用AGU.

请参阅标记wiki,了解在不同的微体系结构上使代码变慢或快速的原因,尤其是 Agner Fog的微体系结构pdf和指令表.

add更糟糕的是因为它让gcc -O0通过将其与内存目标一起使用然后从中加载来制作更糟糕的代码.


编译时-O0甚至不尝试使用最佳指令.例如,你会得到mov $0, %eax而不是xor %eax,%eax你总是得到优化的代码.你不应该推断任何关于什么是从寻找未优化的编译器输出好.

-O0代码总是充满瓶颈,通常是在加载/存储或存储转发时.不幸的是,IACA没有考虑存储转发延迟,所以它没有意识到这些循环实际上是瓶颈


据我所知,一旦在内存被引用之前计算了一个新地址,必须经过一些时钟周期,所以在addl $ 4之后的第二个循环,-12(%ebp)需要稍等一会儿才能继续,

是的,mov负载-12(%ebp)不会,这是部分负荷后准备约6个周期add的读-修改-写.

而在第一个循环中,我们可以立即引用内存

同时LEAL将计算下一个地址

没有.

您的分析很接近,但您错过了下一次迭代仍然需要加载我们存储的值的事实-12(%ebp).所以循环携带的依赖链是相同的长度,并且下一次迭代lea实际上不能比使用循环中的循环更快地启动add


延迟问题可能不是循环吞吐量瓶颈:

需要考虑uop /执行端口吞吐量.在这种情况下,OP的测试显示它实际上是相关的.(或资源冲突造成的延迟.)

当gcc -O0实现时ptr++,它会将旧值保存在寄存器中,就像你说的那样.因此,存储地址可以提前知道,并且需要AGU的负载uop少一个.

假设一个Intel SnB系列CPU:

## ptr++: 1st loop
movl    -12(%ebp), %eax   //1 uop (load)
leal    4(%eax), %edx     //1 uop (ALU only)
movl    %edx, -12(%ebp)   //1 store-address, 1 store-data
//   no load from -12(%ebp) into %eax
... rest the same.


 ## ++ptr:  2nd loop
addl    $4, -12(%ebp)       // read-modify-write: 2 fused-domain uops.  4 unfused: 1 load + 1 store-address + 1 store-data
movl    -12(%ebp), %eax     // load: 1 uop.   ~6 cycle latency for %eax to be ready
... rest the same
Run Code Online (Sandbox Code Playgroud)

所以第二个循环的指针增量部分还有一个加载uop.可能是AGU吞吐量(地址生成单元)的代码瓶颈.IACA表示arch = SNB就是这种情况,但HSW瓶颈存储数据吞吐量(而不是AGU).

然而,在没有考虑存储转发延迟的情况下,IACA表示第一个循环可以每3.5个循环运行一次,而第二个循环每4个循环运行一次.这比addl $1, -48(%ebp)循环计数器的6循环循环携带依赖性更快,这表明循环因延迟而低于最大AGU吞吐量而受到瓶颈.(资源冲突可能意味着它实际上比每6c的一次迭代运行得慢,见下文).

我们可以测试这个理论:

在关键路径之外lea版本添加额外的负载uop 会占用更多吞吐量,但不会成为循环延迟链的一部分.例如

movl    -12(%ebp), %eax   //Get the current address
leal    4(%eax), %edx     //Calculate the next address
movl    %edx, -12(%ebp)   //Store the new (next) address

mov     -12(%ebp), %edx 
Run Code Online (Sandbox Code Playgroud)

%edx即将被a覆盖mov,因此对此负载的结果没有依赖性.(目标mov是只写,所以它打破了依赖链,这要归功于寄存器重命名.).

因此,这个额外的负载会使lea循环达到与循环相同的数量和风格add,但具有不同的延迟.如果额外负载对速度没有影响,我们知道第一个循环在加载/存储吞吐量上没有瓶颈.


更新:OP的测试证实,额外的未使用负载会使lea环路减慢到与环路大致相同的速度add.

当我们没有遇到执行端口吞吐量瓶颈时,为什么额外的uops很重要

uops以最早的第一顺序(在其操作数已准备就绪的uops中)安排,而不是以关键路径优先顺序排列.稍后可能在备用周期中完成的额外微操作将实际上延迟关键路径上的微操作(例如,循环携带依赖性的一部分).这称为资源冲突,可能会增加关键路径的延迟.

也就是说,不是等待关键路径延迟使加载端口无事可做的循环,未使用的加载将在其最早的加载及其加载地址就绪时运行.这将延迟其他负载.

类似地,在add额外负载是关键路径的一部分的循环中,额外负载导致更多资源冲突,延迟关键路径上的操作.


其他猜测:

因此,可能更快就准备好商店地址就是这样做,因此内存操作可以更好地进行流水线操作.(例如,当接近页面边界时,TLB-miss页面遍历可以更快地开始.即使正常的硬件预取也不会跨越页面边界,即使它们在TLB中很热.循环接触4MiB的内存,这对于这种类型的重要的是.L3延迟足够高,可能会产生管道泡沫.或者如果你的L3很小,那么主内存肯定是.

或者,额外的延迟可能会使乱序执行更难以做好工作.