Question

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

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

运行此程序可以缩短 2 的执行时间。这违背了常识，因为 2。每次都要检查if语句。

我的机器上 1 的平均值为105毫秒， 2 的平均值为86毫秒。该演示也显示出差异，但只有5ms的差异仍然有利于 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

与ordering of tests一起玩。

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

Average 1: 159 ms

Average 2: 165 ms

这里＆＃34;平均2＆＃34;首先运行测试。

显然，它可以为以下测试＆＃34;平均1＆＃34;的泵（准备物品）提供质量。

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代码非常相似。请参阅涉及lock add in the asm on godbolt的循环。它们以相同的速度运行（在我的Sandybridge CPU上），仅在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缓存中保持热点，并且每次迭代额外的两个加载uop不应该是一个因素。我没有Nehalem进行测试，所以可能不值得在循环中包装一些register-init代码在SandyBridge上尝试（我没有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位原子计数器会产生无限循环。无论如何，这里不是问题。编写的代码适用于简单的整数类型。

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

4 个答案: