Re: [boost] [boost::endian] Request for comments/interest

Subject: Re: [boost] [boost::endian] Request for comments/interest
From: Tomas Puverle (tomas.puverle_at_[hidden])
Date: 2010-05-28 12:05:41

Thanks Dave,

> 2)      To copy or not to copy.  
<snip>

Dave brings up an important example which I'd like to expand on a little:

Suppose your application generates a large amount of data which may need to be
endian-swapped.  

For the sake of argument, say I've just generated an 10GB array that contains
some market data, which I want to send in little-endian format to some external
device.

In the case of the typed interface, in order to send this data, I would have to
construct a new 10GB array of little32_t and then copy the data from the host
array to the destination array.

This has several problems:
1) It is relying on the fact that the typed class can be exactly overlaid over
the space required by the underlying type.  This is an implementation detail but
a concern nonetheless, especially if, for example, you start packing your
members for space efficiency.

2) The copy always happens, even if the data doesn't need to change, since it's
already in the correct "external" format.  This is useless work - not only does
it use one CPU to do nothing 10 billion times, it also unnecessarily taxes the
memory interfaces, potentially affecting other CPUs/threads (and more, but I
hope this is enough of an illustration)

swap_in_place<>(r) where r is a range (or swap_in_place<>(begin,end), which is
provided for convenience) will be zero cost if no work needs to be done, while
having the same complexity as the above (but only!) if swapping is required. 
With the swap_in_place<>() approach, you only pay for what you need (to borrow
from the C++ mantra)

Tom