Re: [boost] [xint] Performance of fixed-size large integers

Subject: Re: [boost] [xint] Performance of fixed-size large integers
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2011-03-04 20:10:41

Artyom wrote:
>> From: Mathias Gaunard <mathias.gaunard_at_[hidden]>
>> To: boost_at_[hidden]
>> Sent: Fri, March 4, 2011 8:36:05 PM
>> Subject: Re: [boost] [xint] Performance of fixed-size large integers
>> 
>> On 04/03/2011 19:01, Christopher Jefferson wrote:
>> 
>>> There are still  cases where COW can beat move semantics. For
>>> example, I have need of the same  integer in multiple places.
>> 
>> Then you should have all those places refer  to the same integer,
>> not make all those places hold a copy of  it.
>> 
> 
> 
> We can all argue that move is sometimes better then COW and we can
> argue 
> that COW is in past as move semantics is the future.
> 
> I just want to remind few things:
> 
> 1. Most of compiles that use Boost today and will use it for many
>    years do not support rvalue reference and real move semantics.
> 
> 2. As long as it is not in the main stream (and it is not) most of
>    qualified programmers are not going to use std::move as it is not
>    portable and makes the software to depend on very recent compilers
>    versions and on the standard that was not even released yet(!)
> 
> 3. COW is widely used technique. What is very important, is that it
>    is in use in common practice in many libraries and places. It is
>    well understood by good C++ programmers.
> 
> Yes, it is probably good to have support of move semantics but do not
> expect it to me the mainstream in near future.
> 
> So you need to ask yourself:
> 
> 1. Who benefits from COW semantics?
> 2. Who benefits from move semantics?
> 
> I personally think that COW approach would be very useful for most
> of users while move is "nice-to-have".
> 
> And to clarify it: I'm talking about real world and real programmers
> who deal and maintain real code.
> 
> I think that COW approach is the correct approach at this point
> in the real world applications.
> 
> My $0.02

Pass by reference is what real programmers who deal and maintain real code do.  Rather that the false dicotomy between between COW and move lets answer the more fundamental question, why either?  Just use expression templates.  Don't bother to use proto for your expression templates, by the way, it is very easy to do yourself in this simple case.

This whole argument misses the point of optimizing code that uses a bigint class.  You want to reuse the memory allocated in a bigint variable over and over instead of reallocating every time.  Whether you make one unneeded allocation or two is a less important consideration than whether you make one or zero since 2/1 is a lot smaller than 1/0.  If a temporary is generated by the user's code they have already pessimized their code.  I am sorry, but you cannot avoid allocation with a return by value semantic, only expression templates allows you to reuse the storage on the left hand side of the assignment operator.  Return by value is broken whether you use COW or MOVE so how about we focus on fixing it with a nice expression template based operator syntax using pass by reference and documentation that tells the user to avoid generating temporaries if they want to write code that will run as fast as possible.  If they want to write expressions that generate temporaries it will be *no slower* than the current proposal, but at least they will have the option of writing code that is fast.

Right now it looks like the library needs revision before it can be accepted, and a second review is probably in order.  I hope the author will rise the the challenge and overcome his defensiveness to produce something really worthwhile.  As Beman said, this is the sort of thing that could become part of the standard and then compiler writers would give us really good implementation of that spec, so the focus should be on the interface and we shouldn't be in a hurry.  If the best is the enemy of the good, then what is haste the enemy of?  

Regards,
Luke