Re: [boost] [xint] Boost.Move vs Copy-on-Write timings

Subject: Re: [boost] [xint] Boost.Move vs Copy-on-Write timings
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2010-05-02 21:30:37

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

On 05/02/2010 07:17 PM, Jeffrey Lee Hellrung, Jr. wrote:

>>> Move semantics can optimize away some allocations that copy on write
>>> can't [...]
>>
>> The copy-on-write code should optimize that allocation away too, under
>> those circumstances.
> 
> I don't think so, unless your arithmetic operators use by-value
> parameters (allowing copies to be elided).  Assuming you're not using
> expression templates, I would expect an implementation with no move
> semantics to translate "w = x * y + z" to be, effectively,
> 
> T t0 = x * y;
> w = t0 + z;
> 
> which requires 2 allocations minimum (one to store the result of x * y,
> another to store the result of t0 + z). 

Hm... looking at it more closely, I think you're right. There's no way
for the copy code to know that t0 isn't going to be used again, so it
would still allocate a temporary for the addition.

> But, again, if operator+ takes its parameters by-value, you can
> probably get some copies elided in practice and detect that the first
> argument to operator+ has unique ownership, hence is modifiable.

I'm not sure that's right, because if I set it to take its parameters by
value, it would either have to deep-copy those parameters or use
copy-on-write, making the reference count for copy-on-write two, and
preventing it from detecting that either parameter is unique (and thus
temporary). The variables used for the parameters could be used again
later on, so it's still not safe to modify them.

> What's your allocation count for this operation?

Exactly what you said: two allocations.

> Note that move semantics, on the other hand, can directly detect that t0
> is just a temporary (by overloading operator+ on both a
> reference-to-const and an (emulated) rvalue reference), hence the t0 + z
> can be safely replaced with t0 += z (which will possibly avoid a
> reallocation), and the then the new t0 would be moved into w.

I must be missing a trick then, because operator+ just takes constant
references. The library would do those same allocations for the move
stuff too, at present.

operator+ and operator- would be the only ones that could use that
trick, if I'm seeing things right. And it seems to me that I could
emulate move semantics with my current design too, without going through
Boost.Move... I was thinking about that before, when I thought I
shouldn't use Boost.Move because it wasn't yet official. It might be
worth reviving the 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/

iEYEARECAAYFAkveJzoACgkQp9x9jeZ9/wRAqgCglNdO/gFhjcBctCrz1kgYD7IL
NDEAoLJksHKJOZaEpv4H3jMdT7TI+OJI
=YIBU
-----END PGP SIGNATURE-----