[postgis-devel] Validity flag

[Paul Ramsey]

On Fri, Nov 16, 2018 at 1:24 AM Even Rouault <even.rouault at spatialys.com>
wrote:

> > Just for my own knowledge, I knew the possible performance penalty, but
> > what does it mean that RISC does not allow unaligned reads ?
> > Say:
> >
> > double d = *((double*)0x012345677) /* obviously non-aligned on 8 bytes
> > address */
> >
> > What will it do ? Raise a processor fault ? return garbage ?
>
> Depends on the CPU and operating system. I know that Sparc Solaris used to
> SIGBUS on this.


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)

https://begriffs.com/posts/2018-11-15-c-portability.html

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.

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.

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.

P.



Interesting post on ARM behaviourS (emphasis on the plural):
>
> https://medium.com/@iLevex/the-curious-case-of-unaligned-access-on-arm-5dd0ebe24965
>
> Even on x86, if you build your code with -fsanitize=undefined, you'll get
> errors:
>
> $ cat test.c
>
> int main()
> {
>     double two_doubles[2] = {1, 2};
>     char* p = (char*)two_doubles;
>     return *(double*)(p + 1) == 0;
> }
>
> $ clang -fsanitize=undefined test.c -o test &&  ./test
> test.c:5:12: runtime error: load of misaligned address 0x7fff5eaa8481 for
> type 'double', which requires 8 byte alignment
> 0x7fff5eaa8481: note: pointer points here
>  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
>
>
> Unaligned access is undefined behaviour in C, and the source of real
> issues due
> to compilers being too smart sometimes, assuming your code won't do
> unaligned access, and thus using CPU instructions that really assume it.
>
> See http://pzemtsov.github.io/2016/11/06/bug-story-alignment-on-x86.html
> which is
> really enlighting of this.
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20181116/ee79c2b9/attachment-0001.html>