Draft JEP: Vector API
vladimir.x.ivanov at oracle.com
Thu Apr 12 02:49:29 UTC 2018
>> The Vector API can be used without specifying a concrete shape but instead querying for "preferredVectorSpecies" as noted in the JEP description. Vector API is aiming to support generic shape coding as much as possible and explicit shape coding where needed by algorithms. Current implementation under OpenJDK project Panama (vectorIntrinsics branch) only implements 64, 128, 256, and 512 bit vectors as 512 bit is the largest vector supported on Intel platforms.
>> The Java API implementation can be easily extended to support 1024 bit and larger vectors in future by updating the scripts to generate that variant for all of the different types. The tests also have a similar mechanism - so it is straightforward and easy to generate tests for variants of different sizes. Most of the effort needed to support larger vector sizes lies in the architecture specific backend implementation.
> OK, I see the template file. Arm SVE vector size is an implementation
> defined multiple of 128 bits, up to 2048 bits, so that will required a
> lot of internal vector shapes. But since architecturally, those
> different vector sizes in SVE use the same assembly code, I am
> wondering whether these (non-Intel) shapes can be treated as a single
> concrete type of shape. Yes, that's the Java API level, we still need
> to implement them in the backend.
From API perspective, irrespective of actual implementation on ISA
level, vectors are strongly typed by their shape (element type +
length). There's no way to perform an operation on vectors of
incompatible shapes: e.g., it's illegal to add 128-bit vector of ints to
256-bit vector of ints.
The main motivation for class-per-shape implementation now is to help
JIT-compiler to disambiguate (devirtualize & inline) vector operation
implementation down to intrinsifiable primitives: in order to get decent
code generated the whole vector kernel should be fully inlined down to
concrete intrinsic calls (methods on VectorIntrinsic).
If there's a way to move vector shape (or part of it) from separate
class into instance variables on vectors w/o sacrificing code
optimizability, that would be a welcome enhancement simplifying the
implementation on both x86 & ARM.
Regarding dedicated Agnostic shape, as Sandhya & Paul already mentioned,
the API already supports shape-agnostic vector programming approach by
querying the most optimal shape at runtime and using it to construct
More information about the jdk-dev