为什么使用'if'语句会给我更好的表现？

Question

在发布模式下在VC ++ 2015中编译以下程序时，优化设置为Ox（完全优化），即使有额外的条件检查，我也会以某种方式获得更好的性能。

演示： http ： //coliru.stacked-crooked.com/a/a33b42a28548d3e4 （没有演示性能差异，因为g ++为这两个版本生成了几乎相同的代码）。

运行这个程序让我的执行时间更短了2 。 这与我的常识不符，因为2.每次都有一个if语句来检查。

我在我的机器上获得1. 2.平均为105ms和平均86ms。 该演示也显示出差异，但只有5毫秒的差异仍然有利于2 .; 是什么导致了这个？

---

这是完整的代码实际上给了我执行时间的巨大差异。 请注意，它实际上并不使用两个函数。 我只是注释掉operator++()的相关部分。

#include <iostream>
#include <thread>
#include <chrono>
#include <cstddef>
#include <atomic>
#include <limits>
#include <stdexcept>
#include <assert.h>

template <typename T = std::size_t>
class atomic_counter
{
public:
    using size_type = T;

    atomic_counter() : count_{ 0 }
    {
        assert( count_.is_lock_free() );
    }

    atomic_counter& operator++()
    {
        ++count_;                             // 1.
        //auto prev_count = ++count_;         // 2.
        //if ( prev_count == std::numeric_limits<size_type>::min() )
        //  throw std::overflow_error( "atomic_counter::operator++(): counter overflow" );

        return *this;
    }
    atomic_counter& operator--()
    {
        auto prev_count = --count_;
        if ( prev_count == std::numeric_limits<size_type>::max() )
            throw std::underflow_error( "atomic_counter::operator--() : counter underflow" );

        return *this;
    }

    size_type count() const
    {
        return count_.load();
    }

public:
    std::atomic<size_type> count_;
};

template
<
    typename Clock = std::chrono::high_resolution_clock,
    typename Unit = std::chrono::milliseconds,
    typename F,
    typename... FArgs
>
long long measure_execution_time( F&& f, FArgs&&... fargs )
{
    auto time_begin = Clock::now();
    f( std::forward<FArgs>( fargs )... );
    auto time_end = Clock::now();
    return std::chrono::duration_cast<Unit>( time_end - time_begin ).count();
}

int main()
{
    auto hardware_concurrency = std::thread::hardware_concurrency();
    std::size_t constexpr loop_count = 15'000'000;
    atomic_counter<> ac;

    auto lambda = [&] ( auto&& n )
    {
        for ( atomic_counter<>::size_type i{ 0 }; i < n; ++i )
            ++ac;
    };

    long long avg = 0;
    for ( std::size_t i{ 0 }; i < 20; ++i )
    {
        auto time = measure_execution_time<>( lambda, loop_count );
        std::cout << i + 1 << ".\t" << time << " ms\n";
        avg += time;
    }

    std::cout << "Avg:\t" << avg / 20 << " ms\n";
}

为1.一致的结果：

对于2一致的结果：

为1生成的汇编：

000000013FA110F0  lea         rcx,[rsp+38h]  
000000013FA110F5  call        std::chrono::steady_clock::now (013FA11000h)+100000000h  
000000013FA110FA  mov         eax,2160EC0h  
000000013FA110FF  nop  
000000013FA11100 loopv1: mov    ecx,1  
000000013FA11105  lock xadd   qword ptr [ac],rcx  
000000013FA1110C  sub         rax,1  
000000013FA11110  jne    loopv1 ;   main+70h (013FA11100h)  
000000013FA11112  lea         rcx,[rsp+40h]  
000000013FA11117  call        std::chrono::steady_clock::now (013FA11000h)+100000000h

为2生成的汇编：

long long measure_execution_time( F&& f, FArgs&&... fargs )
{
000000013F871230  mov         qword ptr [rsp+8],rbx  
000000013F871235  push        rdi  
000000013F871236  sub         rsp,50h  
000000013F87123A  mov         rdi,rcx  
000000013F87123D  mov         rbx,rdx  
    auto time_begin = Clock::now();
000000013F871240  lea         rcx,[rsp+70h]  
000000013F871245  call        std::chrono::steady_clock::now (013F871110h)  
    f( std::forward<FArgs>( fargs )... );
000000013F87124A  xor         r9d,r9d  
000000013F87124D  cmp         qword ptr [rbx],r9  
000000013F871250  jbe         measure_execution_time<std::chrono::steady_clock,std::chrono::duration<__int64,std::ratio<1,1000> >,<lambda_fb2a7610a6d36531125f2c739fce673b> & __ptr64,unsigned __int64 const & __ptr64>+41h (013F871271h)  
000000013F871252 loopv2: mov    rax,qword ptr [rdi]   ; top of the inner loop
000000013F871255  mov         r8d,1  
000000013F87125B  lock xadd   qword ptr [rax],r8  
000000013F871260  lea         rax,[r8+1]  
000000013F871264  test        rax,rax  
000000013F871267  je          measure_execution_time<std::chrono::steady_clock,std::chrono::duration<__int64,std::ratio<1,1000> >,<lambda_fb2a7610a6d36531125f2c739fce673b> & __ptr64,unsigned __int64 const & __ptr64>+7Bh (013F8712ABh)  
000000013F871269  inc         r9  
000000013F87126C  cmp         r9,qword ptr [rbx]   ; loop upper-bound in memory
000000013F87126F  jb  loopv2  ;         measure_execution_time<std::chrono::steady_clock,std::chrono::duration<__int64,std::ratio<1,1000> >,<lambda_fb2a7610a6d36531125f2c739fce673b> & __ptr64,unsigned __int64 const & __ptr64>+22h (013F871252h)  
    auto time_end = Clock::now();
000000013F871271  lea         rcx,[time_end]  
000000013F871276  call        std::chrono::steady_clock::now (013F871110h)

Answer 1

有趣的测试订购 。

g++ -std=c++17 -O3 -Wall -pedantic -pthread main.cpp && ./a.out

Average 1: 159 ms

Average 2: 165 ms

这里首先运行“平均2”测试。

显然，它可以为下面的“平均值1”测试提供泵（准备工作）。

Answer 2

看起来两个成员函数内联但生成的代码明显不同：

.L5:
        movq    $-1, %rdx
        lock xaddq      %rdx, (%rsp)
        testq   %rdx, %rdx
        je      .L14
        subq    $1, %rax
        jne     .L5

VS

.L3:
        lock addq       $1, (%rsp)
        subq    $1, %rax
        jne     .L3

我在Fedora上使用g ++ 5.1.1，你需要生成程序集（带有-S编译器标志）并查看你的编译器在做什么。 很难想象第一个版本的运行速度要快得多。

Answer 3

编译器应该可以毫无困难地检测到测试程序中永远不会满足if条件。 因此，您的计时是优化中的随机性和其他奇数效应的某种组合; 例如，由于您尚未访问内存，因此第一个循环迭代可能会触发页面错误。

Answer 4

gcc与MSVC的代码不同。 v1和v2代码非常相似。 在godbolt上看到涉及lock add的循环。 它们以相同的速度运行（在我的Sandybridge CPU上），瓶颈lock add仅lock add吞吐量（每19个周期一个，剩余大量执行资源来处理其他指令。请参阅http://agner.org/optimize以了解insn延迟/吞吐量表，以及一些不错的指南。）根据ocperf.py ，gcc的v2每循环运行0.17条指令，每循环0.61微秒（融合域）。

MSVC为v2做了一些奇怪的事情，但我仍然无法解释为什么除了lock xadd吞吐量之外还存在瓶颈，因为锁定的指令非常慢。 我认为可能最重要的唯一区别是v2使用lock xadd的寄存器地址，而不是绝对地址。

lock xadd   qword ptr [ac],rcx    ; v1: ac is a 32bit absolute address

lock xadd   qword ptr [rax],r8    ; v2: rax is a pointer (reloaded from memory every time through the loop)

Agner Fog的微博文档没有详细介绍lock指令如何影响周围指令的执行，例如，它们是否将执行端口占用的时间超过了他们根据解码的uop数量而预期的时间。 他的指令表在Sandybridge之前甚至没有uop计数（可能是因为SnB引入了uop缓存，这使得uop的数量更重要。）

MSVC的v2将指针留给原子变量，并将循环上限（ n ）留在内存中，并在每次迭代时加载它们。 但这应该不是问题。 它们将在L1缓存中保持热点，并且每次迭代时额外的两个加载uops不应该是一个因素。 我没有Nehalem进行测试，因此可能不值得在我的SandyBridge上尝试将一些register-init代码包装在那个循环上（我没有MSVC，甚至没有Windows计算机进行测试）。 我已经看到了额外的内存操作实际上加速了一些代码的情况，但这种情况看起来很奇怪。

并不是uop吞吐量应该是一个因素附近，但根据IACA，循环的底部仍然微观和宏融合到一个比较和分支与内存操作数，在Nehalem。

cmp   r9,qword [rbx]   ; loop upper-bound in memory
jb    loopv2

IACA表示在Nehalem上v2循环总共12个uop。 但是，我认为它不能正确解释锁定指令的有限吞吐量，因为它认为循环将在每3.2个时钟的一次迭代中运行。 它说v1是8 uops，应该每3.0个时钟运行一次。 因此，IACA不会对CPU行为进行足够详细的建模，以说明对此案例有用的任何内容。 两个循环应该从Nehalem上的28uop循环缓冲区运行，而不是前端在每个周期一个指令下面的瓶颈附近！

---

我之前对具有额外MFENCE的代码的猜测是基于误读源，认为循环计数器是原子的，而不仅仅是原子的size_type的整数。 这没有意义，BTW：

循环计数器的大小应该基于迭代计数，而不是你正在测试atomic_counter随机类型。 如果它是一个缓慢的浮点或扩展精度类型或其他东西，你也不想在循环开销中支付罚金。 测试一个8位原子计数器会产生无限循环。 无论如何，这里不是问题。 编写的代码适用于简单的整数类型。