RVO 何时显示出最大的性能影响?
When RVO shows the maximum performance impact?
我花了一点时间试图了解 RVO 性能影响是否和我想象的一样有价值。
这是我的基准代码(主要思想是创建大结构并return它们来自函数):
#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]
有了这样的结果,人们可能倾向于总是使用 returning by value 技术,因为它在语义上看起来更好,即使编译器不提供 RVO。什么时候 RVO 真的会产生显着的性能影响?
Link 到基准 gist.
关于RVO,你应该知道的有两件事:
1。 RVO 不是(常规)编译器优化
听起来很疯狂,因为最后一个 O 代表 "optimization",但让我解释一下。常规编译器优化会保留代码的语义:至少是副作用的顺序和它们之间的依赖关系。 RVO 不用理会这些事情。示例:
#include <cstdio>
using namespace std;
struct foo {
foo () { printf ("foo::foo()\n"); }
foo (const foo&) { printf ("foo::foo( const foo& )\n"); }
~foo () { printf ("foo::~foo()\n"); }
};
foo bar() {
foo local_foo;
return local_foo;
}
int main() {
foo f = bar();
return 0;
}
你对屏幕有什么期待?没有 RVO:
$ g++ -O2 rvo.cc -fno-elide-constructors
$ ./a.out
foo::foo()
foo::foo( const foo& )
foo::~foo()
foo::foo( const foo& )
foo::~foo()
foo::~foo()
使用 RVO:
$ g++ -O2 rvo.cc
$ a.out
foo::foo()
foo::~foo()
没有编译器会以这种方式优化用户代码。但是RVO确实多然后优化:它是编译器在某些情况下盲目的处方。对用户定义的语义视而不见,我是说。
2。 RVO 非常有效
您的基准测试没有利用这一点,因为您没有做 RVO 省略的事情。你做任何普通编译器都可以优化的事情。但是让我们围绕 return 值复制跳舞:
class MyBuf {
int x_;
char *buf_;
public:
MyBuf(int x) : x_(x), buf_(new char[x_]) {}
MyBuf(const MyBuf &rhs) :
x_(rhs.x_), buf_(new char[x_])
{
memcpy (buf_, rhs.buf_, x_);
}
~MyBuf() { delete [] buf_; }
char &operator[](int x) { return buf_[x]; }
};
现在:
MyBuf
retvec()
{
MyBuf v(10000);
v[0] = 1;
return v;
}
哇哦:
for (idx = 0; idx != 1000000; ++idx)
{
MyBuf v = retvec();
cnt += v[0];
}
fprintf (stderr, "cnt is %d\n", cnt);
你会看到:
$ g++ --std=c++11 -O2 rvo-spec.cc -fno-elide-constructors
$ time ./a.out
cnt is 1000000
real 0m1.284s
user 0m1.280s
sys 0m0.000s
$ g++ --std=c++11 -O2 rvo-spec.cc
$ time ./a.out
cnt is 1000000
real 0m0.099s
user 0m0.096s
sys 0m0.000s
对于非常简单的场景,相差超过 12 倍。
我希望我创造了一些 RVO 的感觉,以及为什么你永远不会关闭它。祝你好运!
我花了一点时间试图了解 RVO 性能影响是否和我想象的一样有价值。
这是我的基准代码(主要思想是创建大结构并return它们来自函数):
#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]
有了这样的结果,人们可能倾向于总是使用 returning by value 技术,因为它在语义上看起来更好,即使编译器不提供 RVO。什么时候 RVO 真的会产生显着的性能影响?
Link 到基准 gist.
关于RVO,你应该知道的有两件事:
1。 RVO 不是(常规)编译器优化
听起来很疯狂,因为最后一个 O 代表 "optimization",但让我解释一下。常规编译器优化会保留代码的语义:至少是副作用的顺序和它们之间的依赖关系。 RVO 不用理会这些事情。示例:
#include <cstdio>
using namespace std;
struct foo {
foo () { printf ("foo::foo()\n"); }
foo (const foo&) { printf ("foo::foo( const foo& )\n"); }
~foo () { printf ("foo::~foo()\n"); }
};
foo bar() {
foo local_foo;
return local_foo;
}
int main() {
foo f = bar();
return 0;
}
你对屏幕有什么期待?没有 RVO:
$ g++ -O2 rvo.cc -fno-elide-constructors
$ ./a.out
foo::foo()
foo::foo( const foo& )
foo::~foo()
foo::foo( const foo& )
foo::~foo()
foo::~foo()
使用 RVO:
$ g++ -O2 rvo.cc
$ a.out
foo::foo()
foo::~foo()
没有编译器会以这种方式优化用户代码。但是RVO确实多然后优化:它是编译器在某些情况下盲目的处方。对用户定义的语义视而不见,我是说。
2。 RVO 非常有效
您的基准测试没有利用这一点,因为您没有做 RVO 省略的事情。你做任何普通编译器都可以优化的事情。但是让我们围绕 return 值复制跳舞:
class MyBuf {
int x_;
char *buf_;
public:
MyBuf(int x) : x_(x), buf_(new char[x_]) {}
MyBuf(const MyBuf &rhs) :
x_(rhs.x_), buf_(new char[x_])
{
memcpy (buf_, rhs.buf_, x_);
}
~MyBuf() { delete [] buf_; }
char &operator[](int x) { return buf_[x]; }
};
现在:
MyBuf
retvec()
{
MyBuf v(10000);
v[0] = 1;
return v;
}
哇哦:
for (idx = 0; idx != 1000000; ++idx)
{
MyBuf v = retvec();
cnt += v[0];
}
fprintf (stderr, "cnt is %d\n", cnt);
你会看到:
$ g++ --std=c++11 -O2 rvo-spec.cc -fno-elide-constructors
$ time ./a.out
cnt is 1000000
real 0m1.284s
user 0m1.280s
sys 0m0.000s
$ g++ --std=c++11 -O2 rvo-spec.cc
$ time ./a.out
cnt is 1000000
real 0m0.099s
user 0m0.096s
sys 0m0.000s
对于非常简单的场景,相差超过 12 倍。
我希望我创造了一些 RVO 的感觉,以及为什么你永远不会关闭它。祝你好运!