On Tue, Aug 23, 2011 at 11:12 PM, Gottlob Frege <gottlobfrege@gmail.com> wrote:
On Tue, Aug 23, 2011 at 9:44 AM, Julian Gonggrijp <j.gonggrijp@gmail.com> 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