为什么c ++文件中函数的位置会影响其性能

时间:2013-10-18 13:04:47

标签: c++ performance gcc micro-optimization

为什么c ++文件中函数的位置会影响其性能?具体来说,在下面给出的示例中,我们有两个相同的功能,具有不同的,一致的性能配如何调查这一点并确定性能如此不同?

这个例子很简单,因为我们有两个函数:a和b。每个都在紧密循环中运行多次并优化(-O3 -march=corei7-avx)和定时。这是代码:

#include <cstdint>
#include <iostream>
#include <numeric>

#include <boost/timer/timer.hpp>

bool array[] = {true, false, true, false, false, true};

uint32_t __attribute__((noinline)) a() {
    asm("");
    return std::accumulate(std::begin(array), std::end(array), 0);
}

uint32_t __attribute__((noinline)) b() {
    asm("");
    return std::accumulate(std::begin(array), std::end(array), 0);
}

const size_t WARM_ITERS = 1ull << 10;
const size_t MAX_ITERS = 1ull << 30;

void test(const char* name, uint32_t (*fn)())
{
    std::cout << name << ": ";
    for (size_t i = 0; i < WARM_ITERS; i++) {
        fn();
        asm("");
    }
    boost::timer::auto_cpu_timer t;
    for (size_t i = 0; i < MAX_ITERS; i++) {
        fn();
        asm("");
    }
}

int main(int argc, char **argv)
{
    test("a", a);
    test("b", b);
    return 0;
}

一些值得注意的功能:

  • 功能a和b相同。它们执行相同的累积操作并编译为相同的汇编指令。
  • 每个测试迭代都有一个预热时间,然后开始尝试消除任何加热缓存的问题。

当编译并运行时,我们得到以下输出,显示a明显慢于b:

[me@host:~/code/mystery] make && ./mystery 
g++-4.8 -c -g -O3 -Wall -Wno-unused-local-typedefs -std=c++11 -march=corei7-avx -I/usr/local/include/boost-1_54/ mystery.cpp -o mystery.o
g++-4.8  mystery.o -lboost_system-gcc48-1_54 -lboost_timer-gcc48-1_54 -o mystery
a:  7.412747s wall, 7.400000s user + 0.000000s system = 7.400000s CPU (99.8%)
b:  5.729706s wall, 5.740000s user + 0.000000s system = 5.740000s CPU (100.2%)

如果我们反转两个测试(即调用test(b)然后调用test(a)),a仍然比b慢:

[me@host:~/code/mystery] make && ./mystery 
g++-4.8 -c -g -O3 -Wall -Wno-unused-local-typedefs -std=c++11 -march=corei7-avx -I/usr/local/include/boost-1_54/ mystery.cpp -o mystery.o
g++-4.8  mystery.o -lboost_system-gcc48-1_54 -lboost_timer-gcc48-1_54 -o mystery
b:  5.733968s wall, 5.730000s user + 0.000000s system = 5.730000s CPU (99.9%)
a:  7.414538s wall, 7.410000s user + 0.000000s system = 7.410000s CPU (99.9%)

如果我们现在反转C ++文件中函数的位置(将b的定义移到a之上),结果将被反转,并且变得比b快!

[me@host:~/code/mystery] make && ./mystery 
g++-4.8 -c -g -O3 -Wall -Wno-unused-local-typedefs -std=c++11 -march=corei7-avx -I/usr/local/include/boost-1_54/ mystery.cpp -o mystery.o
g++-4.8  mystery.o -lboost_system-gcc48-1_54 -lboost_timer-gcc48-1_54 -o mystery
a:  5.729604s wall, 5.720000s user + 0.000000s system = 5.720000s CPU (99.8%)
b:  7.411549s wall, 7.420000s user + 0.000000s system = 7.420000s CPU (100.1%)

因此,基本上c ++文件顶部的任何函数都会变慢。

您可能遇到的问题的一些答案:

  • 编译的代码对于a和b都是相同的。已经检查了拆卸。 (对于那些感兴趣的人:http://pastebin.com/2QziqRXR
  • 代码是在ubuntu 13.04,ubuntu 13.10和ubuntu 12.04.03上使用gcc 4.8,gcc 4.8.1编译的。
  • 在Intel Sandy Bridge i7-2600和Intel Xeon X5482 cpu上观察到的效果。

为什么会这样?有哪些工具可以用来调查这样的事情?

2 个答案:

答案 0 :(得分:6)

在我看来,这是一个缓存别名问题。

测试用例非常巧妙,并且在计时之前正确地将所有内容加载到缓存中。看起来所有东西都适合缓存 - 虽然是模拟的,但我已经通过查看valgrind的cachegrind工具的输出来验证这一点,正如人们在这么小的测试用例中所期望的那样,没有明显的缓存未命中:

valgrind --tool=cachegrind --I1=32768,8,64 --D1=32768,8,64  /tmp/so
==11130== Cachegrind, a cache and branch-prediction profiler
==11130== Copyright (C) 2002-2012, and GNU GPL'd, by Nicholas Nethercote et al.
==11130== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==11130== Command: /tmp/so
==11130== 
--11130-- warning: L3 cache found, using its data for the LL simulation.
a:  6.692648s wall, 6.670000s user + 0.000000s system = 6.670000s CPU (99.7%)
b:  7.306552s wall, 7.280000s user + 0.000000s system = 7.280000s CPU (99.6%)
==11130== 
==11130== I   refs:      2,484,996,374
==11130== I1  misses:            1,843
==11130== LLi misses:            1,694
==11130== I1  miss rate:          0.00%
==11130== LLi miss rate:          0.00%
==11130== 
==11130== D   refs:        537,530,151  (470,253,428 rd   + 67,276,723 wr)
==11130== D1  misses:           14,477  (     12,433 rd   +      2,044 wr)
==11130== LLd misses:            8,336  (      6,817 rd   +      1,519 wr)
==11130== D1  miss rate:           0.0% (        0.0%     +        0.0%  )
==11130== LLd miss rate:           0.0% (        0.0%     +        0.0%  )
==11130== 
==11130== LL refs:              16,320  (     14,276 rd   +      2,044 wr)
==11130== LL misses:            10,030  (      8,511 rd   +      1,519 wr)
==11130== LL miss rate:            0.0% (        0.0%     +        0.0%  )

我选择了一个32k,8路关联缓存,其64字节缓存行大小与普通的Intel CPU相匹配,并且反复看到a和b函数之间的差异。

在具有32k,128路关联缓存且具有相同缓存行大小的虚拟机器上运行,但这种差异几乎消失了:

valgrind --tool=cachegrind --I1=32768,128,64 --D1=32768,128,64  /tmp/so
==11135== Cachegrind, a cache and branch-prediction profiler
==11135== Copyright (C) 2002-2012, and GNU GPL'd, by Nicholas Nethercote et al.
==11135== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==11135== Command: /tmp/so
==11135== 
--11135-- warning: L3 cache found, using its data for the LL simulation.
a:  6.754838s wall, 6.730000s user + 0.010000s system = 6.740000s CPU (99.8%)
b:  6.827246s wall, 6.800000s user + 0.000000s system = 6.800000s CPU (99.6%)
==11135== 
==11135== I   refs:      2,484,996,642
==11135== I1  misses:            1,816
==11135== LLi misses:            1,718
==11135== I1  miss rate:          0.00%
==11135== LLi miss rate:          0.00%
==11135== 
==11135== D   refs:        537,530,207  (470,253,470 rd   + 67,276,737 wr)
==11135== D1  misses:           14,297  (     12,276 rd   +      2,021 wr)
==11135== LLd misses:            8,336  (      6,817 rd   +      1,519 wr)
==11135== D1  miss rate:           0.0% (        0.0%     +        0.0%  )
==11135== LLd miss rate:           0.0% (        0.0%     +        0.0%  )
==11135== 
==11135== LL refs:              16,113  (     14,092 rd   +      2,021 wr)
==11135== LL misses:            10,054  (      8,535 rd   +      1,519 wr)
==11135== LL miss rate:            0.0% (        0.0%     +        0.0%  )

由于在8路缓存中,潜在的别名功能可以隐藏的空间较少,因此您获得的寻址相当于更多的哈希冲突。对于具有不同缓存关联性的计算机,在这种情况下,您可以放心地将对象放在对象文件中,因此虽然不是缓存未命中,但您也无需进行任何工作解决实际需要的缓存行。

编辑:有关缓存关联性的更多信息:http://en.wikipedia.org/wiki/CPU_cache#Associativity


另一个编辑:我已通过perf工具通过硬件事件监控确认了这一点。

我修改了源代码只调用a()或b(),具体取决于是否存在命令行参数。时间与原始测试用例相同。

sudo perf record -e dTLB-loads,dTLB-load-misses,dTLB-stores,dTLB-store-misses,iTLB-loads,iTLB-load-misses /tmp/so
a:  6.317755s wall, 6.300000s user + 0.000000s system = 6.300000s CPU (99.7%)
sudo perf report 

4K dTLB-loads
97 dTLB-load-misses
4K dTLB-stores
7 dTLB-store-misses
479 iTLB-loads
142 iTLB-load-misses               

,而

sudo perf record -e dTLB-loads,dTLB-load-misses,dTLB-stores,dTLB-store-misses,iTLB-loads,iTLB-load-misses /tmp/so foobar
b:  4.854249s wall, 4.840000s user + 0.000000s system = 4.840000s CPU (99.7%)
sudo perf report 

3K dTLB-loads
87 dTLB-load-misses
3K dTLB-stores
19 dTLB-store-misses
259 iTLB-loads
93 iTLB-load-misses

显示b具有较少的TLB操作,因此不必逐出缓存。鉴于两者之间的功能相同,它只能通过别名来解释。

答案 1 :(得分:0)

您正在a致电btest。由于编译器没有理由对您的两个函数进行重新排序a距离b test(原始版本)更远。您还使用模板,因此实际代码生成比C ++源代码要大得多。

因此b的指令存储器很可能与test一起进入指令缓存,a距离更远不会进入缓存,因此需要更长的时间从低级缓存或CPU主内存中获取b

因此,由于a的指令获取周期比b长,a的运行速度比b慢,即使实际代码相同,也可能就在远处。

某些CPU架构(例如arm cortex-A系列)支持计算缓存未命中数的性能计数器。像perf这样的工具可以在设置为使用适当的性能计数器时捕获此数据。