[PROJ] Vector/SIMD acceleration

[johan mabille]

Even,
Thanks for your welcoming!

> Do you know if there have been assessments of the accuracy of those
functions, in terms of input range, ULP ?

I know there were measures of accuracy for large input range for almost all
the functions, unfortunately I cannot retrieve them. Maybe they are
available in this [article](
https://www.researchgate.net/publication/261959890_BoostSIMD_generic_programming_for_portable_SIMDization).
I remember reading them on a website, so probably in the documentation of
boost.SIMD. Unfortunately, the repo has been reset and the documentation is
not available anymore.

The drop-in replacement can be found [here](
https://github.com/agenium-scale/nsimd). Although I could not find the data
you're looking for, I think you can open an issue to ask them.

> For the use case I've in mind for PROJ, a potential point of caution for,
let's say a MY_VECTOR_TYPE<double, 4>, would be to make sure it is possible
to have > the same code compiled once with SSE2 (in which case this would
be 2 SSE registers) and once with AVX (would be a AVX register) within the
same library, when > one wants to generate generic binaries with runtime
selection of the implementation

Runtime selection of the right implementation is also something we had in
mind for a long time. A solution would be to add the target instruction set
as an additional parameter of the batch (the xsimd equivalent of the vector
you mentioned). This way it becomes possible to instantiate batches of the
same size for different instructions sets and have them in a same library.
Selection can then be done at build time (with a facade template class that
dispatches to the right implementation), or at runtime when loading the
library (but I am not sure how to implement this yet).


On Mon, Apr 20, 2020 at 10:41 AM Even Rouault <even.rouault at spatialys.com>
wrote:

> Johan,
>
>
>
> > Joris Van Den Bossche drew my attention on this thread as I co-authored
>
> > xsimd. I am not here to advertise my own library, but rather to give a
> bit
>
> > of context about xsimd.
>
>
>
> Advertizing open source software is always fine :-) Thanks for all this
> information.
>
>
>
> > By the way, most of the advanced mathematical functions come from there.
>
>
>
> Do you know if there have been assessments of the accuracy of those
> functions, in terms of input range, ULP ?
>
>
>
> > However,
>
> > we see more an more interest in having the possibility to instantiate
>
> > vectors that map to more than one register withouth requiring to pull
>
> > another complex library with totally unrelated features. So we are
>
> > considering implementing this feature as well in xsimd.
>
>
>
> I think that could be useful indeed. Perhaps through a dedicated type, so
>
> that the user really knows what they do (and potentially have to check
> impact on register use by looking at assembly)
>
>
>
> For the use case I've in mind for PROJ, a potential point of caution for,
> let's say a MY_VECTOR_TYPE<double, 4>, would be to make sure it is possible
> to have the same code compiled once with SSE2 (in which case this would be
> 2 SSE registers) and once with AVX (would be a AVX register) within the
> same library, when one wants to generate generic binaries with runtime
> selection of the implementation. If the type has exactly the same name in
> the -msse and -mavx enabled objects, that could result in
> One-Definition-Rule violation, and, beyond that theoretical concern, in
> real symbol clashes if some big functions aren't inlined. I can imagine
> that could be solved by allowing some way to override / add something to
> the namespace of the header that would define such type. Or maybe something
> smarter :-)
>
>
>
> Even
>
>
>
> --
>
> Spatialys - Geospatial professional services
>
> http://www.spatialys.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20200422/57b9e0a4/attachment.html>