Re: [boost] [xint] Third release is ready, requesting preliminary review

Subject: Re: [boost] [xint] Third release is ready, requesting preliminary review
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2010-05-03 17:55:12

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.
- -- 
Chad Nelson
Oak Circle Software, Inc.
*
*
*
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvfRj0ACgkQp9x9jeZ9/wQwvwCgtCUiDrDRdHZvjg8EBqdzXDxY
raEAoOY4N5VFF1qlHSNBFehbW8QpgpHD
=z0hb
-----END PGP SIGNATURE-----