AntoinePrv commented on issue #47769:
URL: https://github.com/apache/arrow/issues/47769#issuecomment-4222732099
I've been looking into this.
First xsimd does not currently support SVE2, but as Antoine said, it is not
easy to find instances, meaning the demand is likely limited at the present
time.
Second, SVE introduce a significant departure from the general SIMD model,
which is that the register/batch size is a dynamic constant. One can write SVE
code, and it can work with 256 or 2048 register sizes, sort of a built-in
dynamic dispatch!
The issue with this is that xsimd had not yet adapted this model, and
requires to know the size at compile time (there is compiler option to force it
to a given size). Regardless of this, few of our algorithm (integer unpacking,
byte stream split that I know of) also currently require to know the size at
compile time.
As such I suggest we introduce hard coded macros
`ARROW_HAVE_RUNTIME_SVE(256|512)`, `ARROW_RUNTIME_SIMD_LEVEL+=SVE256,SVE512`
(these two sizes feel like a good start).
We currently have `ARROW_HAVE_SVE${SVE_VECTOR_BITS}`, which is gated behind
`if(SVE_VECTOR_BITS)` (else `ARROW_HAVE_SVE_SIZELESS`). This may be departing
from this, as we would need to supply multiple ones in the dynamic case (but
only one in the static case), though we can make it work with some more CMake
checks.
I am not aware of any code in Arrow using this macros, perhaps some are
using it with auto vectorization capabilities.
What do you think @pitrou, seems like a good direction?
Also CC @raulcd on whether we have an SVE CI (otherwise how to set it up).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
