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

Subject: Re: [boost] [boost::endian] Request for comments/interest
From: Terry Golubiewski (tjgolubi_at_[hidden])
Date: 2010-06-03 11:38:58

Tomas Puverle wrote:

> First of all, *thank you* for going into all this trouble and writing the
> code.

I needed to write some code to understand your use-case.
Benchmarks are always criticized, especially hastily created ones.
However, it's important to code something because "best" always implicitly 
implies a "for what".
Doing this has enhanced my awareness of endianess issues (and I thought I 
already knew everything).
I'm considering adding an endian_convert_in_place<endian_t, T>(T& x) 
function to my library, that will be implemented using std::swap.
So *thank you* for raising my awareness, and hopefully others are monitoring 
this thread as well.

>> I have some problems with your tests.
>
> I was going to make the same points as Robert, but he beat me to it.
> Additionally (I don't think this was mentioned), I don't think the
> verification should be part of the test, either.

As Robert pointed out, it should do something with the result, otherwise the 
whole thing could be optimized away by a clever compiler.
Plus, the assert has alerted me to over-zealous optimizations.
Its the same overhead for both tests, so it shouldn't affect the results.

>> > When the disk-data-file was in little endian, both approaches
>> > came in at around 6 seconds.

Both approaches seem to do nothing.  That's as it should be.

I'm just using cygwin's "time" command to evaluate the results.
So the times given represent program initialization/deinitialization; 
generating and writing the data file; opening, reading and closing the 
datafile for each iteration; and verifying that the conversion was correct 
for each iteration using memcmp.
I'm not trying to measure how fast each approach is in absolute terms.  Just 
given a common test app, how do the resulting times compare.  The overhead 
should be the same in both cases.

> This, I think, you'll find is the overhead of reading the file &
> verification.  In the little endian data case, swap_in_place<>() does
> nothing! :)

Both approaches seem to do nothing in the same-endian case.
>
>> > Swap Based: 18 seconds
>> > Type Based   14 seconds
>
> This is unexpected...

Swap-then-copy is less efficient than just a reverse copy (in the general 
case).
These differences are more significant than I expected.  If we allow 9 
seconds for the disk i/o and memcmp, then the overhead is approximately

Type-based: 36% overhead  (14-9)/14
Swap-based: 50% overhead (18-9)/18.

> Thanks again.  If there is a performance discrepancy between swap (soon to 
> be
> endian_cast<>) and the object-based approach, I will make sure to fix it,
> of course.

If you implement endian_cast<> using a reverse-copy instead of swapping, you 
will see a performance improvement.

terry