On 5/3/2010 2:55 PM, Chad Nelson wrote:
On 05/03/2010 02:26 PM, Jeffrey Lee Hellrung, Jr. wrote:
RVO works independently of (emulated) move semantics. [...]
If that's the case, and GCC is doing that as it should, why would adding move semantics to the library provide any speed increase at all?
Hmmm...good question. For something like "w = x * y + z", if you can't reuse any resources, I don't think move semantics will give you anything other than optimizing the final assignment... [...]
Sorry, I meant why does adding Boost.Move make any difference to the timings I posted yesterday at all, if the compiler is already eliding the copy operations on return values even without it? If I understand what you're trying to explain (which is far from certain), there's no need to wrap the return values in a boost::move call, but in that case Boost.Move should be completely superfluous -- the code should run at the same speed with or without it.
I just realized that, since I have the boost::move calls wrapped in a #define already, it would be easy to check on that, so I did. The timings all indicate that without the boost::move() call for the return values, XInt runs as if Boost.Move weren't even there. So the boost::move call *is* required to get the benefits of emulated move semantics, as I originally thought.
Sorry, I *definitely* should've added that, as far as I know, RVO generally requires a single, simple return statement. If you have multiple returns, or a return expression more complicated than "return foo;" or "return T(bar,zap);", then I don't think RVO typically kicks in. Can you confirm or deny this to be the case? If it is, then the move(...) calls or COW will almost certainly be necessary to get optimal performance. Again, my apologies for maybe oversimplifying the situation and misleading you. See http://en.wikipedia.org/wiki/Return_value_optimization for more information on RVO. - Jeff