【发布时间】:2016-08-19 10:31:54
【问题描述】:
我花了一点时间试图了解 RVO 性能影响是否与我想象的一样有价值。
这是我的基准代码(主要思想是创建大结构并从函数中返回它们):
#include <chrono>
#include <iostream>
#include <stdlib.h>
#include <time.h>
#define SIZE_MEDIUM 128
#define SIZE_LARGE 8192
#define ITER_COUNT 100000
using namespace std;
using namespace std::chrono;
struct MediumStruct {
int data[SIZE_MEDIUM];
};
struct LargeStruct {
int data[SIZE_LARGE];
};
template<typename T>
T by_value(int size) {
T rv;
for (int i = 0; i < size; i++) {
rv.data[i] = rand();
}
return rv;
}
template<typename T>
void by_ref(T &v, int size) {
for (int i = 0; i < size; i++) {
v.data[i] = rand();
}
}
template<typename T>
void bench_by_value(int size, const string &suite) {
high_resolution_clock::time_point t1 = high_resolution_clock::now();
int counter = 0;
for (int i = 0; i < ITER_COUNT; i++) {
T r = by_value<T>(size);
for (int j = 0; j < size; j++) {
counter += r.data[j];
}
}
high_resolution_clock::time_point t2 = high_resolution_clock::now();
auto duration = duration_cast<milliseconds>(t2 - t1).count();
cout << "By value (" << suite << ") " << duration << " ms "
<< "[stub " << counter << "]" << endl;
}
template<typename T>
void bench_by_ref(int size, const string &suite) {
high_resolution_clock::time_point t1 = high_resolution_clock::now();
int counter = 0;
for (int i = 0; i < ITER_COUNT; i++) {
T r;
by_ref<T>(r, size);
for (int j = 0; j < size; j++) {
counter += r.data[j];
}
}
high_resolution_clock::time_point t2 = high_resolution_clock::now();
auto duration = duration_cast<milliseconds>(t2 - t1).count();
cout << "By ref (" << suite << ") " << duration << " ms "
<< "[stub " << counter << "]" << endl;
}
int main() {
srand(time(NULL));
bench_by_value<MediumStruct>(SIZE_MEDIUM, "MEDIUM");
bench_by_value<LargeStruct>(SIZE_LARGE, "LARGE");
bench_by_ref<MediumStruct>(SIZE_MEDIUM, "MEDIUM");
bench_by_ref<LargeStruct>(SIZE_LARGE, "LARGE");
}
在我的 MacBook Pro 上,这个基准测试显示了在使用和不使用 RVO 优化的情况下几乎相同的性能。
$g++ --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 7.3.0 (clang-703.0.31)
Target: x86_64-apple-darwin15.2.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
$g++ -std=c++11 -S -o /dev/stdout main.cpp | grep memcpy | wc -l
0
$g++ -std=c++11 -fno-elide-constructors -S -o /dev/stdout main.cpp | grep memcpy | wc -l
4
$ g++ -std=c++11 main.cpp
$ ./a.out
By value (MEDIUM) 123 ms [stub -1593461165]
By value (LARGE) 7741 ms [stub -1299931242]
By ref (MEDIUM) 120 ms [stub -1955762550]
By ref (LARGE) 7835 ms [stub 911248215]
$ ./a.out
By value (MEDIUM) 118 ms [stub 2094615909]
By value (LARGE) 7840 ms [stub -1276864738]
By ref (MEDIUM) 118 ms [stub -223778153]
By ref (LARGE) 7890 ms [stub -381745773]
$ g++ -std=c++11 -fno-elide-constructors main.cpp
$ ./a.out
By value (MEDIUM) 122 ms [stub 1921645226]
By value (LARGE) 8078 ms [stub 1869896539]
By ref (MEDIUM) 123 ms [stub -676968691]
By ref (LARGE) 7855 ms [stub 1621698360]
$ ./a.out
By value (MEDIUM) 119 ms [stub 954834819]
By value (LARGE) 7779 ms [stub 98742842]
By ref (MEDIUM) 118 ms [stub 1498384025]
By ref (LARGE) 7505 ms [stub -118604845]
拥有这样的结果,人们可能倾向于总是使用按值返回技术,因为即使编译器不提供 RVO,它在语义上看起来也更好。 RVO 何时真正对性能产生重大影响?
链接到基准gist。
【问题讨论】:
-
SIZE_LARGE不是特别大,并且您的测试结构都没有用户定义的复制或移动构造函数,因此在您的特定情况下 RVO 没有巨大的好处并不令我感到惊讶. -
@CharlesBailey,好的,用户定义的构造函数可能很重。让我们暂时假设没有这样的ctrs。在堆栈上分配这么大的对象是一种常见的做法吗? 8 kB 是一个大对象吗?如果不是,那么对于真正的大物体来说,合理的尺寸是多少?
-
@CharlesBailey 刚刚在 64kB 结构上进行了测试,得到了 66.088s 与 65.156s 的结果。尺寸大了 8 倍,但看起来还是一样。
-
我会查看几兆字节大小的对象,尽管如此,对 rand 的调用将随对象大小线性缩放,并且在任何情况下都可能主导返回时的复制成本。
-
@CharlesBailey,关于
rand(),谢谢!将rand()替换为memset()并重试。
标签: c++ gcc compiler-optimization return-value-optimization rvo