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

Subject: Re: [boost] [xint] Boost.Move vs Copy-on-Write timings
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-05-03 01:45:34

----- Original Message ----- 
From: "Chad Nelson" <chad.thecomfychair_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, May 03, 2010 1:04 AM
Subject: Re: [boost] [xint] Boost.Move vs Copy-on-Write timings

> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 05/02/2010 06:43 PM, Peter Dimov wrote:
> 
>>> Times are measured in seconds, using two sets of ten 2048-bit integers.
>>> The tests consisted of adding each of those pairs of numbers together
>>> 10,000 times, multiplying them 10,000 times, and doing a "mulmod"
>>> operation on them (with a third randomly-generated 2048-bit modulus
>>> argument) 1,000 times. Each test was run three times, under as close to
>> 
>> Move semantics can optimize away some allocations that copy on write
>> can't, such as for example
>> 
>> w = x * y + z;
>> 
>> (assuming that x*y already has enough bits to store x*y+z).
> 
> The copy-on-write code should optimize that allocation away too, under
> those circumstances.

This expression should construct two -rvalues and one move and no assignement.

x*y must result in a r-value which is passed to operator +

r-value (x*y) + z must result in a r-value 

w = r-value(r-value (x*y) + z) restult in one move operation.

If your implmentation doesnt do that you it is not surprissing that the move emulation is less performant than COW.
 
>> But it doesn't have to be either-or; you can move even when copy on
>> write is used.
> 
> I tested that in my original tests, but it didn't seem to be useful. The
> results were halfway between move-only and copy-on-write-only, so I
> eliminated it for this round.

I agree with Peter that both mechanism are orthogonal. For example.

x=y;
y=a+b;
...

should result in a COW for x=y; and a move for y=a+b;

Best,
Vicente