3 ms·

It's not mentioned how that test program was compiled nor assembler code is given. Might be some kind of an optimization made by the compiler. At least on ARM,

by kbart 12y ago

It's not mentioned how that test program was compiled nor assembler code is given. Might be some kind of an optimization made by the compiler. At least on ARM, unaligned access really does affect performance negatively, even the company itself[1] states that: "[Unaligned] Accesses typically take a greater number of cycles to complete compared to a naturally aligned transfer." 1. http://infocenter.arm.com/help/topic/com.arm.doc.ddi0333h/Cdffhdje.html http://infocenter.arm.com/help/topic/com.arm.doc.ddi0333h/Cd...

dalke 12y ago
The first line of the code shows how it was compiled. The end of the essay says "Recent ARM processors do support unaligned memory accesses though it is unclear what the performance penalty is." and points to basically the same documentation you did.
- nkurz 12y ago
  The first line of the code shows how it was compiled. 'kbart' does have a point: it's always risky talk about hardware behaviour as if C++ code actually specifies what processor is doing. And while the first line shows the flags, one could argue that without the version number for g++ you still don't know what the compiler has done. But in this case, it does seem that gcc-4.7 and gcc-4.8 both produce more less the code that you'd expect when compiling with -O2. But to show that compiler behaviour is not just an idle worry, icpc 14.0.3 -O3 produces much faster times by realizing it can combine the loops and completely omit the reads. And g++ -O3? Oh, it segfaults, because it tries to optimize to a 128-bit 'movdqa' (Move Double-Quadword Aligned) that requires 16B alignment. While unhelpful, I think it's technically legal for it to do this, as (incredibly?) reading an unaligned int directly from memory is actually undefined behaviour. But I guess I'd prefer if it just used the equally performant 'movdqu' (Move Double-Quadword Unaligned) instead, so it worked rather than crashing. Separately, here's a more recent post coming to the same general conclusion as Daniel: http://cdglove98.blogspot.com/2014/05/the-performance-of-unaligned-simd-loads.html http://cdglove98.blogspot.com/2014/05/the-performance-of-una...

by kbart 12y ago

dalke 12y ago

The first line of the code shows how it was compiled. The end of the essay says "Recent ARM processors do support unaligned memory accesses though it is unclear what the performance penalty is." and points to basically the same documentation you did.

nkurz 12y ago
The first line of the code shows how it was compiled. 'kbart' does have a point: it's always risky talk about hardware behaviour as if C++ code actually specifies what processor is doing. And while the first line shows the flags, one could argue that without the version number for g++ you still don't know what the compiler has done. But in this case, it does seem that gcc-4.7 and gcc-4.8 both produce more less the code that you'd expect when compiling with -O2. But to show that compiler behaviour is not just an idle worry, icpc 14.0.3 -O3 produces much faster times by realizing it can combine the loops and completely omit the reads. And g++ -O3? Oh, it segfaults, because it tries to optimize to a 128-bit 'movdqa' (Move Double-Quadword Aligned) that requires 16B alignment. While unhelpful, I think it's technically legal for it to do this, as (incredibly?) reading an unaligned int directly from memory is actually undefined behaviour. But I guess I'd prefer if it just used the equally performant 'movdqu' (Move Double-Quadword Unaligned) instead, so it worked rather than crashing. Separately, here's a more recent post coming to the same general conclusion as Daniel: http://cdglove98.blogspot.com/2014/05/the-performance-of-unaligned-simd-loads.html http://cdglove98.blogspot.com/2014/05/the-performance-of-una...