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 22:05:59

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

On 05/02/2010 09:42 PM, Jeffrey Lee Hellrung, Jr. wrote:

>> 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.
> 
> If the compiler does a decent job at copy elision (and most recent ones
> do, as I understand), then your reference count will be just 1. [...]

Hm. I can see how that would be possible. I'll have to check into it.

>> 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
> 
> All the free operators / functions could be overloaded on
> lvalue-/rvalue-ness, not just operator+ and operator-.  Any operation
> where you can potentially save reallocations by modifying the arguments
> directly qualifies for consideration.

Exactly what I was saying -- operator+ and operator- are the only ones
where it would be likely to save any allocations. The results from
operator*, for example, will be larger than the bit-length of the
largest parameter. Most other operations can't safely operate directly
on their parameters, because they have to have the entire parameters
available until the end.

It's possible that the parameters (to something like operator*) would
have enough allocated space from previous operations that one of them
could be re-used, but it wouldn't happen very often compared to addition
and subtraction, and it would save very little time compared to the time
required to do the operation itself. I doubt that it would be worth the
effort to implement. It could be iffy even for addition, where the
answer only requires one bit more than the largest parameter at most.

>> 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.
> 
> That's certainly an option, though it sounds like Ion is prepping
> Boost.Move for final submission, so the review for it shouldn't be *too*
> far down the line...

Yup. We'll see. I won't worry about it until there's a good reason to,
I've got plenty of other stuff I could usefully do.
- -- 
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/

iEYEARECAAYFAkveL4cACgkQp9x9jeZ9/wSafACgtxvDpyoO22Ctahe+k5cQQUvD
1awAoNEPTFlv0uQs1tvPTEinT0JfBYH1
=K8G0
-----END PGP SIGNATURE-----