What is the impact of C++11 move semantics in the context of scientific computing?

Question

C++11 introduces move semantics which can, for example, improve code performance in situations where C++03 would need to perform a copy construction or copy assignment. This article reports that following code experiences a 5x speed up when compiled with C+11:

vector<vector<int> > V;
for(int k = 0; k < 100000; ++k) {
    vector<int> x(1000);
    V.push_back(x);
}

What is the impact of C++11 move semantics in the context of scientific computing?

I'm interested in this question is general but more specifically I'm also interested in move semantics for Finite Element codes written using boost libraries. I tested some of my own C++03 code using boost version 1.47.0 (since boost release notes mention move semantics are introduced in 1.48.0) and boost version 1.53.0, but I didn't notice much improvement. I guess any savings from not having to do copy-construction for boost::numeric::ublas::vector/matrix and boost::function are not noticeable since solving system matrices constitutes the bulk of the workload.

Edit: Actually it looks like move semantics are only implemented for boost::function (see version 1.52.0 release notes). There is no mention of move semantics in boost::numeric, I grepped the sources to make sure and there seem to be no rvalue references.

As you note in the last part of your question, unless you've profiled your code and seen a lot of copying going on, you cannot substantially improve your performance by using move semantics. — Bill Barth, Apr 09 '13 at 16:16

score 10 · Accepted Answer · answered Apr 10 '13 at 03:39

I think in practice the impact is limited and will be limited.

The reason why it is limited right now is that the big finite element packages are careful to write code that is portable, and so they do not yet use C++11 language constructs in their own codes.

Of course, they will benefit from code like the one you show where, even without having to change the source code, you benefit from an improved compiler support library such as libstdc++ for GCC. That said, people in scientific computing are pretty well aware of the expense of copying and so, for objects where it matters, they simply don't copy -- they either generate in-place, or they do shallow copies, or they use shared pointers, or many of the other techniques available to avoid the overhead of copying. In other words, the situation for which move semantics were invented does not actually happen very often in "real" scientific codes.

What is the impact of C++11 move semantics in the context of scientific computing?

1 Answers1