gpt4 book ai didi

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

转载 作者:IT老高 更新时间:2023-10-28 21:58:29 25 4
gpt4 key购买 nike

为什么函数在 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 之上),结果会反转并且 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 是相同的。已检查拆卸。 (感兴趣的 friend :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 上观察到的效果。

为什么会发生这种情况?有哪些工具可用于调查此类问题?

最佳答案

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

测试用例非常聪明,在计时之前正确地将所有内容加载到缓存中。看起来一切都适合缓存 - 虽然是模拟的,但我已经通过查看 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 路缓存中,潜在别名函数可以隐藏的空间更少,因此您获得的寻址等效于更多哈希冲突。使用具有不同缓存关联性的机器,在这种情况下,您很幸运能够将事物放置在目标文件中,因此虽然不是缓存miss,但您也不必做任何工作来解决您实际需要的缓存行。

编辑:关于缓存关联性的更多信息: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 操作,因此不必逐出缓存。鉴于两者之间的功能在其他方面相同,只能通过别名来解释。

关于c++ - 为什么函数在c++文件中的位置会影响其性能,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/19450422/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com