Hacker News Reader

Comment by cbmuser | Hacker News Reader

That looks like it could result in unaligned access and hence a crash on sparc64.

How? We’re just reading from a byte array.

The optimized code assumes it can read a full 32 bit value at once. So at least that is only valid on a platform that doesn't assume that 32 bit loads are aligned and the actual compiled code would look a lot worse on platforms that do.

Thus, it can't compile that way for sparc64.

That’s fine, GCC on sparc will generate the sequence to do an unaligned read with the right endianess. If that means reading bytes and shifting them, so be it.

Exactly. And even if we want to optimize access for those architectures, there surely must be ways to do that. Maybe compilers already do that if you use alignas(int32_t) on the byte array at the call site and ensure that read_int32() function of mine gets inlined?

No they won’t, if not in very basic cases that can’t be generalized as a rule of thumb solution. Your suggestion bargains correctness with performance.

If you know you are reading aligned memory and you need to do it with a single word memory access, then you need to use intNN_t* and use htonl or similar functions to byteswap. There’s no way around it.

The compiler can generate a test for alignment, and then a branch between two pieces of code. However, if the test and branch branch causes pipeline stalls due to bad prediction, it could be worse than just running the byte-banging code unconditionally.

I.e. "if that means doing what the programmer literally expressed, so be it."

Reply on news.ycombinator.com