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

Subject: Re: [boost] [xint] Performance of fixed-size large integers
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2011-03-04 12:46:06

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.