Boost logo

Boost :

Subject: Re: [boost] [xint] Third release is ready, requesting preliminary review
From: Jeffrey Lee Hellrung, Jr. (jhellrung_at_[hidden])
Date: 2010-05-03 14:26:02


On 5/3/2010 11:11 AM, Chad Nelson wrote:
> On 05/03/2010 01:45 PM, Jeffrey Lee Hellrung, Jr. wrote:
>
>>>> And I wonder about "return BOOST_XINT_MOVE(p);" instead of
>>>> "return p;" and let the compiler optimise the return via NRVO...
>>>
>>> Does NRVO work with emulated move semantics? I was under the
>>> impression that it couldn't, but I could well be wrong, Boost.Move
>>> is new to me.
>>
>> RVO works independently of (emulated) move semantics. [...] One of
>> the main things (emulated) move semantics gives you is the ability to
>> overload functions on lvalue or (emulated) rvalue reference, giving
>> you the opportunity to capture temporaries and pilfer/reuse their
>> resources.
>
> 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...but then you could always
accept your argument to operator= by value and swap it with *this
(indeed, this is how a move assignment operator was emulated in the
original Boost.Move code). COW should have similar performance. As
pointed out by another (forgive me for not wanting to dig through this
thread to find out exactly who), "w = x * y + z" would be maximally
optimized by using expression templates.

Perhaps someone could correct me if the above is misguided...?

If you *can* reuse resources in some operators, it will help. But it
seems plausible, as you said, that maybe only operator+ and operator-
qualify, and these probably wouldn't be bottlenecks in typical usage.

It's possible that your internal implementations could make use of
moving resources around, but it could also be equally expressible via
swapping (your intentions just may not be as obvious).

- Jeff


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk