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
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
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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk