Draft JEP: Vector API (original) (raw)

Vladimir Ivanov 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 vector kernels.

Best regards, Vladimir Ivanov

More information about the jdk-dev mailing list