為什么c ++文件中函數的位置會影響其性能

Question

為什么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 ）
• 代碼是使用gcc 4.8，gcc 4.8.1在ubuntu 13.04，ubuntu 13.10和ubuntu 12.04.03上編譯的。
• 在Intel Sandy Bridge i7-2600和Intel Xeon X5482 cpu上觀察到的效果。

為什么會這樣？ 有哪些工具可以調查這樣的事情？

Answer 1

它看起來像是一個緩存別名問題。

測試用例非常巧妙，並且在計時之前將所有內容正確加載到緩存中。 看起來所有東西都適合緩存 - 雖然是模擬的，但我已經通過查看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操作，因此不必逐出緩存。 鑒於兩者之間的功能在其他方面是相同的，它只能通過別名來解釋。

Answer 2

你正在test a和b 。 由於編譯器沒有理由重新排序兩個功能a是漸行漸遠的是b從（原） test 。 您還使用模板，因此實際的代碼生成比它在C ++源代碼中看起來要大得多。

因此，很可能是對指令存儲器b進入指令緩存連同test ， a是漸行漸遠沒有進入高速緩存，因此需要更長的時間，從低了下去緩存或CPU主內存中獲取b 。

因此，這可能是因為較長的取指令周期為a比b ， a跑慢b即使實際的代碼是一樣的，它僅僅是漸行漸遠。

某些CPU架構（例如arm cortex-A系列）支持計算緩存未命中數的性能計數器。 像perf這樣的工具可以在設置為使用適當的性能計數器時捕獲此數據。