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

Subject: Re: [boost] [xint] Performance of fixed-size large integers
From: Christopher Jefferson (chris_at_[hidden])
Date: 2011-03-04 13:01:39

On 4 Mar 2011, at 17:46, Mathias Gaunard wrote:

> On 04/03/2011 17:53, Chad Nelson wrote:
>> On Fri, 04 Mar 2011 17:36:15 +0100
>> Mathias Gaunard<mathias.gaunard_at_[hidden]>  wrote:
>> 
>>>>> I ran no benchmarks but delving through magnitude_manager_t seems
>>>>> enough to understand the problem. Do you think specializing this
>>>>> class on Bits parameter to be stack based for non zero values could
>>>>> solve this performance problem?
>>>> 
>>>> <http://permalink.gmane.org/gmane.comp.lib.boost.devel/205549>
>>> 
>>> Just drop the whole copying everywhere and COW idea, it's just making
>>> your code more complex and preventing many simple optimizations.
>> 
>> My, you're good. I've never before met anyone who can profile code in
>> his head and come up with the optimal solution without even touching a
>> compiler. My hat is off to you, sir.
>> 
>> If, after fixing the pass-by-reference stuff, testing proves that the
>> COW code isn't an improvement, I'll certainly remove it. If not, you're
>> welcome to pound salt.
> 
> It's not a matter of profiling, it's a matter of logic.
> 
> The point of COW is that if you copy but you don't really want to copy (i.e. you're not going to write to your copy), then you don't have to perform a deep copy, only a shallow copy.
> 
> But if you copy only if you really *need* to copy, then there is no use whatsoever for COW, since every shallow copy will end up doing a write and invoking the real deep copy.
> Because if you didn't need to write to it and not affect the original, you wouldn't copy it in the first place.
> 
> The point of move semantics is to allow you to not have to copy something when you don't really need to, making COW completely obsolete for scenarios that do not involve partial sharing.
> 
> This is a fact and a reality, not something you can disprove with benchmarks.

There are still cases where COW can beat move semantics. For example, I have need of the same integer in multiple places.

I have found immutable COW strings (without thread safety) still beat copying, move semantic aware strings on projects I work on, although the move semantics has massively closed the gap. Also my fellow developers often don't "std::move" things as often as they could.

I'm not sure in practice if there is likely to be much call for producing copies of integers, as opposed to moving them, or accepting them to functions by reference, but I wouldn't discard COW completely without benchmarks.

I do agree however that in general functions should be changed to accept by reference, unless in those functions the integer itself would be changed of course.