Re:A bug story: data alignment in C on x86 (2016)
by userbinator on Tuesday September 04, 2018 @10:18PM
(#17914594)
Alignment issues are not only relevant for RISC processors. SSE makes them valid for x86, too (in both 32 and 64-bit mode).
Requiring alignment with certain SSE instructions was the original poorly-thought-out misstep that lead to this bug. One of the basic principles of CISC is to implement instructions flexibly in hardware even if it requires microcode, then optimise that hardware to gain a performance advantage with each new generation.
If the original SSE instructions worked fine with unaligned data, perhaps being slower in such cases like all the other instructions did, then no expectations would be violated and everything would've worked out nicely. The fact that the explicitly unaligned version is now actually slightly faster in the benchmarks shown (because there doesn't need to be extra code to do alignment) is evidence enough that the original decision to have separate aligned/unaligned versions was really shortsighted. Very wide memory buses and multistage pipelines make alignment pretty much a non-issue.
The other big point this article doesn't mention is that rather than fighting with the compiler, if you already know what instructions you want, it would be better to write the Asm directly. For short sequences like these the Asm is going to be even clearer and shorter than "truly portable" C. In practice there really aren't that many architectures your code is going to run on.
Requiring alignment with certain SSE instructions was the original poorly-thought-out misstep that lead to this bug. One of the basic principles of CISC is to implement instructions flexibly in hardware even if it requires microcode, then optimise that hardware to gain a performance advantage with each new generation.
If the original SSE instructions worked fine with unaligned data, perhaps being slower in such cases like all the other instructions did, then no expectations would be violated and everything would've worked out nicely. The fact that the explicitly unaligned version is now actually slightly faster in the benchmarks shown (because there doesn't need to be extra code to do alignment) is evidence enough that the original decision to have separate aligned/unaligned versions was really shortsighted. Very wide memory buses and multistage pipelines make alignment pretty much a non-issue.
The other big point this article doesn't mention is that rather than fighting with the compiler, if you already know what instructions you want, it would be better to write the Asm directly. For short sequences like these the Asm is going to be even clearer and shorter than "truly portable" C. In practice there really aren't that many architectures your code is going to run on.