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-23 23:16:36

On Tue, Aug 23, 2011 at 11:12 PM, Gottlob Frege <gottlobfrege_at_[hidden]> wrote:
> On Tue, Aug 23, 2011 at 9:44 AM, Julian Gonggrijp <j.gonggrijp_at_[hidden]> wrote:
>> Christopher Jefferson wrote:
>>
>>> Can you first of all give a good example (with source) of where using move_raw would out-perform move assignment / constructors from C++0x, particularly in any standard library function (random_shuffle has a fairly small implementation for example). I don't really see how it will help that much.
>>
>> There is a very simple reason why move_raw will outperform move
>> assignment for any non-POD type:
>>
>> move assignment = move_raw + fixing up the source object ,
>>
>
> 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*.  It is very hard to tell - it
> depends on the amount of data, the locality of the data, the type of
> CPU/memory/bus/architecture, etc etc etc.
> But I wouldn't be that surprised if raw_move offered no speed up in most cases.
>
> Tony
>

Particularly if you are still calling raw_move one container element at a time.
If you really want to speed things up, you need to memcpy a whole
block of objects at once.  ie an array/vector of pods.
If 100 elements is 100 memcpy calls, I'm not sure you will get much benefit.
If we can get 100 elements to compile into 1 memcpy call, there is a
chance at a speed up.  A good memcpy is hand optimized for the given
architecture to prime the cache as it moves along, etc.  That only
works if it is one big call.

Tony