Re: [boost] [proposal] raw move (was: [interest] underlying type library)

Subject: Re: [boost] [proposal] raw move (was: [interest] underlying type library)
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2011-08-24 10:08:35

On Wed, Aug 24, 2011 at 7:00 AM, Julian Gonggrijp <j.gonggrijp_at_[hidden]> wrote:
> Gottlob Frege wrote:
>
>> On Tue, Aug 23, 2011 at 11:12 PM, Gottlob Frege <gottlobfrege_at_[hidden]> wrote:
>>>
>>> raw_move assumes that later the algorithm will raw_move back into the
>>> temporarily invalid source object.  So sooner or later we write to
>>> that memory.  Depending on caching scenarios, it might actually be
>>> faster to write to that memory *sooner*.
>
> We can write sooner, but that doesn't change anything to our need to
> write later, does it? So either we write soon with zeros and later
> with the new value, or we write only later with the new value.
>
> Or are you saying that the compiler might be able to predict what
> value we're going to move later and move that value sooner?
>
> Or was your point maybe that reading the source object of a raw move
> might not be enough to promote it in the cache, and that writing it
> with zeros instead will therefore improve the speed of retrieval when
> the object has become the target of a new raw move?
>

Closest to this one.  I'm mostly saying
1. once cached, an extra write might not have an overall cost
2. changing when the caching happens can have strange affects - it
depends what else is going on.  If it happens to better balance and
better time CPU work with memory-bus work, it is typically faster.
Hand optimizing assembler often involves reordering instructions to
get this balance.

And/or, typically, if the algorithm is memory bound, less memory
writes might help, but if it CPU bound, it doesn't matter.

Tony