<div dir="ltr"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Nov 16, 2018 at 1:24 AM Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Just for my own knowledge, I knew the possible performance penalty, but<br>
> what does it mean that RISC does not allow unaligned reads ?<br>
> Say:<br>
> <br>
> double d = *((double*)0x012345677) /* obviously non-aligned on 8 bytes<br>
> address */<br>
> <br>
> What will it do ? Raise a processor fault ? return garbage ?<br>
<br>
Depends on the CPU and operating system. I know that Sparc Solaris used to SIGBUS on this.</blockquote><div><br></div><div>PostGIS 0.x was developed primarily on a Sun Ultra 10 workstation running Solaris 6. And yes, it would SIGBUS on unaligned access, so PostGIS was developed with some care about aligned access (though 1.0 handled the problem by copying data out of the serialization into an aligned buffer for access)</div><div><br></div><div><a href="https://begriffs.com/posts/2018-11-15-c-portability.html">https://begriffs.com/posts/2018-11-15-c-portability.html</a><br></div><div><br></div><div>The experience with the Ultra may have made me over-sensitive to alignment issues, but I also integrated in a conversation I had with Bob Bray back in the Autodesk FDO days, where he explained that they'd used "aligned WKB" as their binary transport, and I asked why and he noted performance reasons. If you read into it a little, you'll find that unaligned access does require the CPU do do "more thinking" before it can get the value, basically under the covers it does the same thing as the software copying fix: it finds the two parts via aligned access and then sticks them together into an aligned space for further processing.</div><div><br></div><div>That said, I did some very simplistic testing a few years ago and could coerce a measurable performance difference between aligned and unaligned access to a simple contiguous buffer of doubles. Probably this is because my access pattern was a sequential scan, so CPU caching neatly papered over most of the bad parts.</div><div><br></div><div>I would say that ignoring alignment is a "no go". If we choose an unaligned serialization, that's OK, but we have to align the data before accessing it, which might involve no incremental cost if we're doing things like decompressing anyways.</div><div><br>P.</div><div> </div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Interesting post on ARM behaviourS (emphasis on the plural):<br>
<a href="https://medium.com/@iLevex/the-curious-case-of-unaligned-access-on-arm-5dd0ebe24965" rel="noreferrer" target="_blank">https://medium.com/@iLevex/the-curious-case-of-unaligned-access-on-arm-5dd0ebe24965</a><br>
<br>
Even on x86, if you build your code with -fsanitize=undefined, you'll get errors:<br>
<br>
$ cat test.c<br>
<br>
int main()<br>
{<br>
    double two_doubles[2] = {1, 2};<br>
    char* p = (char*)two_doubles;<br>
    return *(double*)(p + 1) == 0;<br>
}<br>
<br>
$ clang -fsanitize=undefined test.c -o test &&  ./test<br>
test.c:5:12: runtime error: load of misaligned address 0x7fff5eaa8481 for type 'double', which requires 8 byte alignment<br>
0x7fff5eaa8481: note: pointer points here<br>
 7f 00 00  00 00 00 00 00 00 f0 3f  00 00 00 00 00 00 00 40  80 85 aa 5e ff 7f 00 00  00 00 00 00 00<br>
<br>
<br>
Unaligned access is undefined behaviour in C, and the source of real issues due<br>
to compilers being too smart sometimes, assuming your code won't do<br>
unaligned access, and thus using CPU instructions that really assume it.<br>
<br>
See <a href="http://pzemtsov.github.io/2016/11/06/bug-story-alignment-on-x86.html" rel="noreferrer" target="_blank">http://pzemtsov.github.io/2016/11/06/bug-story-alignment-on-x86.html</a> which is<br>
really enlighting of this.<br>
<br>
-- <br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a></blockquote></div></div></div>