Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk