为什么函数在c++;文件会影响其性能 为什么C++文件中函数的位置会影响它的性能?具体来说,在下面给出的示例中,我们有两个相同的函数,它们具有不同、一致的性能配置文件。我们如何着手调查这一点,并确定性能为何如此不同
这个例子非常简单,因为我们有两个函数:a和b。每个都在一个紧密的循环中运行多次,并经过优化(为什么函数在c++;文件会影响其性能 为什么C++文件中函数的位置会影响它的性能?具体来说,在下面给出的示例中,我们有两个相同的函数,它们具有不同、一致的性能配置文件。我们如何着手调查这一点,并确定性能为何如此不同,c++,performance,gcc,micro-optimization,C++,Performance,Gcc,Micro Optimization,这个例子非常简单,因为我们有两个函数: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};
-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;
}
如果我们颠倒两个测试(即调用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
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%)
[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之上),结果会被反转,A会变得比B更快!p>
[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都是相同的。已检查拆卸情况。(有兴趣的人士:)
- 代码是在Ubuntu13.04、Ubuntu13.10和Ubuntu12.04.03上使用GCC4.8、GCC4.8.1编译的
- 在Intel Sandy Bridge i7-2600和Intel Xeon X5482 CPU上观察到的效果
为什么会发生这种情况?有哪些工具可用于调查类似情况?您正在从
测试调用a
和b
。由于编译器没有理由对两个函数重新排序,因此a
比b
(在原始版本中)离test
更远。您也使用模板,所以实际代码生成比C++源中看起来的要大很多。
因此,b
的指令内存很可能与test
一起进入指令缓存,a
越远,就越不会进入缓存,因此从较低的缓存或b
的CPU主内存取数所需的时间越长
因此,由于a
的指令提取周期比b
长,a
的运行速度可能比b
慢,即使实际代码是相同的,也只是距离更远
某些CPU架构(如arm cortex-A系列)支持计算缓存未命中数的性能计数器。当设置为使用适当的性能计数器时,诸如的工具可以捕获此数据。在我看来,这是一个缓存别名问题
这个测试用例非常聪明,并且在计时之前将所有内容正确地加载到缓存中。看起来所有东西都适合缓存-虽然是模拟的,但我已经通过查看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路缓存中,潜在的别名函数可以隐藏的空间更少,因此可以获得与更多哈希冲突相当的寻址。对于具有不同缓存关联性的计算机,在本例中,您很幸运地找到了对象文件中的位置,因此,虽然没有缓存丢失,但您也不必做任何工作来解析实际需要的缓存线
编辑:有关缓存关联性的详细信息:
另一个编辑:我已经通过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操作,因此不必逐出缓存。考虑到两者的功能在其他方面是相同的,只能用别名来解释。它们是否可能在不同的页面上结束,从而导致额外的工作?我觉得奇怪的是,CPU时间是在系统度量中,而不是在用户度量中。这意味着不是运行用户代码需要时间,而是代表进程的一些操作系统级别的事情。作为一个完整的暗中拍摄,我建议b会话由于首先运行会话而更加预热…(编辑:哦,你们倒了…@DaveS,我相信时间都在用户空间的土地上。循环预热循环(测量前)应该充分预热缓存和分支预测。哦,误读了输出,你说的时间是对的。虽然我仍然很好奇它是如何调用函数的,因为我能看到的区别是函数在哪里。也许尝试将函数a/b移动到它们自己的对象?只是看看它是否有我认为,如果碰巧其中一个不能完全保存在缓存中,而另一个可以保存,那么这种情况可能会发生。