Re: [boost] [Endian] Performance

Subject: Re: [boost] [Endian] Performance
From: Beman Dawes (bdawes_at_[hidden])
Date: 2011-09-09 17:13:17

On Fri, Sep 9, 2011 at 3:14 PM, john filo <filo_at_[hidden]> wrote:
>
> On 09/09/2011 10:45 AM, Beman Dawes wrote:
>>
>> I'm missing something. Could you please post the full function, without any
>> preprocessing statements, where the aliasing issue is arising?
>
> I should have provided more context.  Sorry about that.  It was an addition to the body of the byteswap function in Phil's test code that sparked this whole performance discussion.  With all the various byteswap implementations stripped away, the code becomes:
>
>    #include <cstdint>
>    #include <iostream>
>    #include <boost/endian/integers.hpp>
>
>    using std::uint32_t;
>    using namespace boost::endian;
>
>    static inline uint32_t byteswap(uint32_t src)
>    {
>        return *reinterpret_cast<const ubig32_t*>(&src);
>    }
>
>    int main()
>    {
>        uint32_t s = 0;
>        for (uint32_t i = 0; i < 1000000000; ++i)
>            s += byteswap(x[i]);
>
>        std::cout << s << "\n";
>     }
>
> I did this to compare timing of your endian<> class to your reorder functions, and to show that the former was considerably more efficient than the latter and that you could just implement reorder() in terms of endian<> using the reinterpret_cast above.
>
> I don't fully grasp the C++ aliaising rules, but Matt claims the above reinterpret_cast can (or does) result in undefined behavior.  In this particular case, gcc doesn't complain about any aliasing problems and it does produce the correct answer, but that doesn't mean my code is correct.

I'm not sure I do either. I'd be curious to see a reference to the
wording in the standard that Mathias thinks comes into play.

I'm also curious what you didn't just write:

     return reinterpret_cast<ubig32_t>(src);

But I'm probably trying to follow too many threads, and missing
something obvious.

--Beman