淺談c++性能測試工具google benchmark
一、測試對象
這次測試的對象是標準庫的vector,我們將會在vs2019 16.10和Linux + GCC 11.1上進行測試。為瞭代碼寫著方便,我還會啟用c++17支持。
這次的疑問來自於《A Tour of C++》這本書,最近在重新翻閱本書的時候發現書裡第九章給出瞭一個很有意思的建議:盡量少用reserve方法。
我們都知道reserve會提前分配足夠大的內存來容納元素,這樣在push_back時可以減少內存分配和元素移動的次數,從而提高性能。所以習慣上如果我們知道vector中存儲元素的大致數量,就會使用reserve提前進行內存分配,這是典型的“空間換時間”。
而書中給出的理由僅僅是說vector的內存分配器性能已經很高,預分配往往是多此一舉,收效甚微。事實到底如何呢,性能問題光靠腦補是不能定位的,所以我們用實驗結果說話。
二、使用模板函數生成測試
測試用例的設計很簡單,我們定義普通vector和reserve過的vector,然後分別對其添加一定數量的元素(逐步從少到多)測試性能。
同時vector本身是泛型容器,所以為瞭測試的全面性我們需要測試兩至三種類型參數。
如果針對每一種情況寫測試函數,顯然違反瞭DRY原則,因為除瞭vector的類型參數不同,其他代碼幾乎是完全一樣的。
對於上面的需求,就需要模板測試函數登場瞭:
template <typename T, std::size_t length, bool is_reserve = true> void bench_vector_reserve(benchmark::State& state) { for (auto _ : state) { std::vector<T> container; if constexpr (is_reserve) { container.reserve(length); } for (std::size_t i = 0; i < length; ++i) { container.push_back(T{}); } } }
非常的簡單,我們通過length
控制插入的元素個數;is_reserve
則負責控制是否預分配內存,通過if constexpr
可以生成reserve和不進行任何操作的兩種代碼。
然後我們像往常一樣定義一個測試用例:
BENCHMARK(bench_vector_reserve<std::string,100>);
可是等我們編譯的時候卻報錯瞭!
$ g++ test.cpp -lpthread -lbenchmark -lbenchmark_main
test.cpp:19:48: 錯誤:宏“BENCHMARK”傳遞瞭 2 個參數,但隻需要 1 個
19 | BENCHMARK(bench_vector_reserve<std::string,100>);
| ^
In file included from a.cpp:1:
/usr/local/include/benchmark/benchmark.h:1146: 附註:macro “BENCHMARK” defined here
1146 | #define BENCHMARK(n) \
|
test.cpp:19:1: 錯誤:‘BENCHMARK’不是一個類型名
19 | BENCHMARK(bench_vector_reserve<std::string,100>);
原因是這樣的,在編譯器處理宏的時候實際上不會考慮c++語法,所以分割模板參數的逗號被識別成瞭分割宏參數的逗號,因此在宏處理器的眼裡我們像是傳瞭兩個參數。這也說明瞭BENCHMARK
是處理不瞭模板的。
不過別擔心,Google早就想到這種情況瞭,所以提供瞭BENCHMARK_TEMPLATE
宏,我們隻需要把模板名字和需要的類型參數依次傳給宏即可:
BENCHMARK_TEMPLATE(bench_vector_reserve, std::string, 100); BENCHMARK_TEMPLATE(bench_vector_reserve, std::string, 1000); BENCHMARK_TEMPLATE(bench_vector_reserve, std::string, 10000); BENCHMARK_TEMPLATE(bench_vector_reserve, std::string, 100000); BENCHMARK_TEMPLATE(bench_vector_reserve, std::string, 100, false); BENCHMARK_TEMPLATE(bench_vector_reserve, std::string, 1000, false); BENCHMARK_TEMPLATE(bench_vector_reserve, std::string, 10000, false); BENCHMARK_TEMPLATE(bench_vector_reserve, std::string, 100000, false);
現在就可以正常編譯運行瞭:
可以看到reserve過的容器性能幾乎比默認的快瞭一倍。
不過在揭曉為什麼書上不推薦reserve的謎底之前,我們的代碼還有可以簡化的地方。
三、定制測試參數
首當其沖的問題其實還是違反瞭DRY原則——除瞭數字,其他內容都是重復的。
看到這種代碼直覺就告訴我該做些改進瞭。
Ranges
接受start和end兩個int64_t類型的參數,默認從start起每次累乘8,一直達到end。
通過RangeMultiplier
我們可以改變乘數,比如從8改成10。
在這裡我們的length參數其實是不必要的,所以代碼可以這樣改:
template <typename T, bool is_reserve = true> void bench_vector_reserve(benchmark::State& state) { for (auto _ : state) { std::vector<T> container; if constexpr (is_reserve) { // 通過range方法獲取傳入的參數 container.reserve(state.range(0)); } for (std::size_t i = 0; i < state.range(0); ++i) { container.push_back(T{}); } } } BENCHMARK_TEMPLATE(bench_vector_reserve, std::string)->RangeMultiplier(10)->Range(10, 10000 * 10); BENCHMARK_TEMPLATE(bench_vector_reserve, std::string, false)->RangeMultiplier(10)->Range(10, 10000 * 10);
現在我們測試的元素數量是[10, 100, 1000, 10^4, 10^5]
。
除此之外還有另一種叫“密集參數”的Ranges。google benchmark提供瞭DenseRange
方法。
這個方法的原型如下:
DenseRange(int64_t start, int64_t end, int64_t step);
Ranges
是累乘,而DenseRange
是累加,因為累乘會導致幾何級數的增長,在數軸上的分佈越來越稀疏,累加則看上去像是均勻分佈的,因此累加的參數生成器被叫做密集參數生成器。
如果我們把測試用例這麼改:
BENCHMARK_TEMPLATE(bench_vector_reserve, std::string)->DenseRange(1000, 100 * 100, 1000);
現在我們的length就是這樣一個序列:[1000,2000,3000, ...,9000,10000]
。
關於自定義參數最後一個知識點是ArgsProduct
。看名字就知道這是一個參數工廠。
ArgsProduct(const std::vector< std::vector<int64_t> >& arglists);
std::vector<int64_t>
實際上就是一組參數,arglists就是多組參數的合集,他們之間會被求笛卡爾積,舉個例子:
BENCHMARK(BM_test)->ArgsProduct({ {"a", "b", "c", "d"}, {1, 2, 3, 4} }); // 等價於下面的 BENCHMARK(BM_test)->Args({"a", 1}) ->Args({"a", 2}) ->Args({"a", 3}) ->Args({"a", 4}) ->Args({"b", 1}) ->Args({"b", 2}) ->Args({"b", 3}) ... ->Args({"d", 3}) ->Args({"d", 4})
我們可以看到參數工廠其實得自己手寫所有參數,那如果我想配合工廠使用Ranges呢?
沒問題,benchmark的開發者們早就想到瞭,所以提供瞭下面這些幫助函數:
benchmark::CreateRange(8, 128, /*multi=*/2) // 生成:[8, 16, 32, 64, 128] benchmark::CreateDenseRange(1, 6, /*step=*/1) // 生成:[1, 2, 3, 4, 5, 6]
如果換成我們的例子,就可以這樣寫:
BENCHMARK_TEMPLATE(bench_vector_reserve, std::string)->ArgsProduct({ benchmark::CreateRange(10, 10000*10, 10) }); BENCHMARK_TEMPLATE(bench_vector_reserve, std::string, false)->ArgsProduct({ benchmark::CreateRange(10, 10000*10, 10) });
借助僅僅兩行代碼我們就能生成數量可觀的測試用例:
當然,這隻是一個類型參數,實際上我們還有另外兩個類型需要測試。另外這是1.5.5新增的功能,如果你想嘗鮮得先升級google benchmark。
四、進一步簡化
通常做到上面那一步就足夠瞭,然而在這裡我們還有優化空間,因為如果我們把其他兩個測試用的類型加上,代碼是這樣的,MyClass的定義後面會給出:
BENCHMARK_TEMPLATE(bench_vector_reserve, std::string)->ArgsProduct({ benchmark::CreateRange(10, 10000*10, 10) }); BENCHMARK_TEMPLATE(bench_vector_reserve, std::string, false)->ArgsProduct({ benchmark::CreateRange(10, 10000*10, 10) }); BENCHMARK_TEMPLATE(bench_vector_reserve, std::size_t)->ArgsProduct({ benchmark::CreateRange(10, 10000*10, 10) }); BENCHMARK_TEMPLATE(bench_vector_reserve, std::size_t, false)->ArgsProduct({ benchmark::CreateRange(10, 10000*10, 10) }); BENCHMARK_TEMPLATE(bench_vector_reserve, MyClass)->ArgsProduct({ benchmark::CreateRange(10, 10000*10, 10) }); BENCHMARK_TEMPLATE(bench_vector_reserve, MyClass, false)->ArgsProduct({ benchmark::CreateRange(10, 10000*10, 10) });
你看見瞭什麼?沒錯,重復重復重復!我們又違背瞭DRY原則。
重復說不上什麼十惡不赦,但能避免還是要避免的,所以我準備用宏來簡化這些代碼:
#define generate_test(type) \ BENCHMARK_TEMPLATE(bench_vector_reserve, type)->ArgsProduct({benchmark::CreateRange(10, 100000, 10)}); \ BENCHMARK_TEMPLATE(bench_vector_reserve, type, false)->ArgsProduct({benchmark::CreateRange(10, 100000, 10)}); generate_test(std::string); generate_test(std::size_t); generate_test(MyClass);
這下舒服多瞭。
接著來看我們的MyClass,我們的MyClass包含幾個虛函數,禁止移動賦值,同時被刻意設計成瞭非平凡復制,這樣的類型可以說是繞過瞭標準庫容器設計的大部分優化措施,算是個妥妥的反面教材,希望你的項目裡盡量不要出現這種東西:
class MyClass { public: long i = 2L; MyClass() { i = 2L; } virtual ~MyClass() {} virtual long get() { return i; } MyClass& operator=(MyClass&&) = delete; MyClass(const MyClass& obj) { i = obj.i; } MyClass& operator=(const MyClass& obj) { i = obj.i; } };
這個類其實就是針對內存分配器實現的,vector在重新進行內存分配後很可能靠移動語義或者memmove來移動數據,這兩者將導致重新分配內存導致的性能損失變小,不利於我們觀察vector的行為,所以我定制瞭這個類。
這是Windows上的結果,Linux上也差不多,到目前為止我們看到reserve過的vector有著驚人的性能,那書裡說的到底是怎麼回事呢?
五、揭曉答案
實際上上面測試的都是我們明確知道vector一定會被插入N個元素不多不少的情況。
然而這種情況其實在開發中是不多見的,更多的時候我們隻能得到vector裡元素數量的平均數、眾數,甚至是一個沒什麼可靠依據的經驗值。
所以試想一下這種情況,reserve給的參數是1000,而我的vector總是會插入1001~1005個參數,顯然1000是不夠的,除瞭reserve外還會進行一次內存分配,而且這次分配後很可能還需要把原先的元素都轉移過去(realloc不是總能找到合適的位置擴展已有內存,而且像MyClass那樣的類在c++17中是不能bitwise復制的),那麼這樣的開銷究竟如何呢?我們還是拿測試說話。
篇幅有限,所以我隻能簡單模擬一下上述情況:
template <typename T, bool is_reserve = true> void bench_vector_reserve(benchmark::State& state) { for (auto _ : state) { std::vector<T> container; if constexpr (is_reserve) { container.reserve(state.range(0)); } // 每次多插入兩個元素,這樣多半會導致一次內存分配(當然不保證一定會) for (std::size_t i = 0; i < state.range(0)+2; ++i) { container.push_back(T{}); } } }
編譯均使用Release模式和默認的優化級別,這是Linux上的測試結果:
和我們預期的一樣,多出來的一次內存分配使reserve帶來的性能優勢蕩然無存。
有意思的是Windows上的結果:
奇怪的事情發生瞭,雖說多出的一次分配縮小瞭性能差距,但reserve任然帶來瞭明顯的優勢。
這裡我就不賣關子瞭,我們直接看vector的源碼。
首先是GCC11.1的,代碼在/usr/include/c++/11.1.0/bits
目錄下,分散在vector.tcc
和stl_vector.h
中,其中push_back在容器內存不夠的時候會用_M_realloc_insert
重新分配足夠的內存,這個函數在vector.tcc
的432行有定義,使用_M_check_len
計算重新分配的內存大小。
_M_check_len
是關鍵,定義在stl_vector.h
的1756行:
// Called by _M_fill_insert, _M_insert_aux etc. size_type _M_check_len(size_type __n, const char* __s) const { if (max_size() - size() < __n) __throw_length_error(__N(__s)); const size_type __len = size() + (std::max)(size(), __n); return (__len < size() || __len > max_size()) ? max_size() : __len; }
__n在push_back的時候是1,所以不難看出GCC的vector的擴容策略是每次擴容一倍。
vs2019的stl實現開源在瞭github。關鍵代碼在這裡,push_back在內存不夠的時候會調用_Emplace_reallocate,裡面會調用_Calculate_growth
計算重新分配的內存大小:
_CONSTEXPR20_CONTAINER size_type _Calculate_growth(const size_type _Newsize) const { // given _Oldcapacity and _Newsize, calculate geometric growth const size_type _Oldcapacity = capacity(); const auto _Max = max_size(); if (_Oldcapacity > _Max - _Oldcapacity / 2) { return _Max; // geometric growth would overflow } const size_type _Geometric = _Oldcapacity + _Oldcapacity / 2; // 關鍵代碼 if (_Geometric < _Newsize) { return _Newsize; // geometric growth would be insufficient } return _Geometric; // geometric growth is sufficient }
_Newsize相當於前面GCC的__n,在push_back的時候是1,所以不難看出vs2019的vector增長策略是每次擴容0.5倍。
除此之外兩者的剩餘部分大同小異,都是先分配新內存,然後在新內存裡構建要插入的元素,再把其他元素移動到新內存裡,就連移動元素的方式也差不多,都是先嘗試memmove,接著試試移動語義,最後讓復制操作兜底。
那麼兩者肉眼可見的區別就隻有擴容策略這一條瞭。所以這會帶來什麼影響呢?看個例子:
#include <iostream> #include <vector> void test1(std::size_t len) { std::vector<int> v1, v2; v2.reserve(len); for (std::size_t i = 0; i < len; ++i) { v1.push_back(1); v2.push_back(1); } std::cout << "v1: " << v1.capacity() << '\n'; std::cout << "v2: " << v2.capacity() << '\n'; } void test2(std::size_t len) { std::vector<int> v1, v2; v2.reserve(len); for (std::size_t i = 0; i < len + 1; ++i) { v1.push_back(1); v2.push_back(1); } std::cout << "v1: " << v1.capacity() << '\n'; std::cout << "v2: " << v2.capacity() << '\n'; } int main() { test1(100000); test2(100000); } /* vs2019的運行結果: v1: 138255 v2: 100000 v1: 138255 v2: 150000 GCC11.1.0的結果: v1: 131072 v2: 100000 v1: 131072 v2: 200000 */
如果是一個有10萬個元素的vector想要擴容,GCC就會比vs多分配50000個元素需要的內存,分配如此多的內存需要花費更多的時間,即使reserve帶來瞭性能優勢在這一步也都揮霍的差不多瞭。
激進的擴容策略讓GCC出現瞭明顯的性能波動,不過這隻是出現上面那樣測試結果的原因之一,兩個標準庫的allocator實現上的區別也可能是其中一個原因。不過msvc的分配器實現並不公開,所以最終是什麼導致瞭上述的結果並不能輕易斷言。
六、總結
我們學習瞭如何使用模板和參數生成器創建大量測試用例,以提高編寫測試的效率。
我們還順便瞭解瞭vector.reserve對性能的影響,總結規律有幾條:
1.如果明確知道vector要存放元素的具體數量,推薦reserve,性能提升是有目共睹的;
2.否則你不應該使用reserve,一來有提前優化之嫌,二是在使用libstdc++的程序上會產生較大的性能波動;
3.接上一條,reserve使用不當還會造成內存的浪費。
看來《A Tour of C++》的作者隻說對瞭一半,這也證明瞭性能問題不能靠臆斷,一定要靠測試來定位、解決。
以上就是淺談c++性能測試工具google benchmark的詳細內容,更多關於c++性能測試工具google benchmark的資料請關註WalkonNet其它相關文章!
推薦閱讀:
- C++超詳細講解模擬實現vector
- C++ STL _ Vector使用及模擬實現
- C++ STL標準庫std::vector的使用詳解
- C++ STL vector的模擬實現
- C++中vector的模擬實現實例詳解