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-04 02:49:16

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

On 05/04/2010 02:03 AM, Jeffrey Lee Hellrung, Jr. wrote:

>>> Sorry, I *definitely* should've added that, as far as I know, RVO
>>> generally requires a single, simple return statement. [...]
>>
>> In the cases I'm looking at, there are usually only three lines in the
>> function: a declaration of an integer to hold the return value, a call
>> to a function in the detail namespace to do the operation (with the
>> return value object as a parameter), and a return of the return value.
>> - From what you're saying, RVO should be easy for the compiler to use,
>> but the boost::move call on that return value is still required to get
>> the benefits of move semantics.
>>
>> (That three-line function design is what is preventing the move
>> semantics from working as well as they could, I'm pretty sure. I haven't
>> had enough time to confirm that yet though.)
> 
> Hmmm....can you give a stripped-down example of where you expect (or,
> perhaps, where I claim) RVO should kick in, but doesn't?

We may be talking about two different things. I was responding to
Juergen Hunold's comment about whether the calls to boost::move (via the
BOOST_XINT_MOVE macro) were necessary, and suggesting that I could
increase efficiency by leaving the boost::move part out and letting the
compiler optimize the return via NRVO. I tested it and proved that, at
least for emulated move semantics, the boost::move call was necessary to
get any benefit out of Boost.Move.

I thought that the "three line function design" I mentioned might be at
least partly responsible for why the copy-on-write design is faster than
move semantics, but after looking at the way it's set up, I'm not so
sure about that anymore. I didn't have enough time to actually test it
today, but it's high on my to-do list for tomorrow.

> I tried the following program to test RVO, and emulated the basic 
> function structure you describe above. [...] With MSVC9, debug build
> gives output "X::X()"/"X::X(const X&)", while release build gives
> output "X::X()" (i.e., no call to X::X(const X&)).

Hm... I'm not sure what to make of that, because if it's true (and I'm
not doubting it), Boost.Move shouldn't make any difference whatsoever --
the code should be just as fast or faster without it. But Boost.Move
*does* provide a measurable speed increase over not using it (when
copy-on-write isn't being used in either case).

In any case, that's pretty strong evidence that that design isn't
responsible for the difference. Assuming, of course, that GCC is doing
the same thing, which I'll confirm as soon as I can tomorrow.
- -- 
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/

iEYEARECAAYFAkvfw2kACgkQp9x9jeZ9/wRQigCfTx5XJZ4d0Kss/fOa9UnFOTon
LeUAoMmAGHO05ND/6OulA/lQ7T2CFfzx
=Y6pm
-----END PGP SIGNATURE-----