Draft JEP: Vector API

[Paul Sandoz]

Hi,

Expanding a little further on shapes.

After some more thought i have my doubts that an explicit preferred shape is required. Vector computations can be written generic to shape and there is no need to expose a public type for a preferred shape (however, for optimal code generation the generic computations need to get inlined). Hiding the preferred shape behind a wildcard gives more flexibility since an existing public shape could be reused (as is the case right now), or something private, which might be the case for ARM SVE.

Speculating for ARM SVE i could imagine a single concrete implementation associated with a private preferred platform shape (the bit size and length methods would need to be made intrinsic so as to return constant values). It's probably not optimal to pre-generate given the bit size is platform specific (IIRC it can vary from 128 to 2048 bits in powers of 2). If say the preferred bit size is > 512 then the pre-defined public shapes of 64 to 512 bits could “virtualize” with masks onto the preferred vector. Our intrinsic strategy will likely need adaptating to support this, but thats an internal detail.  

Thanks,
Paul.

> On Apr 11, 2018, at 3:48 PM, Viswanathan, Sandhya <sandhya.viswanathan at intel.com> wrote:
> 
> Hi Ningsheng,
> 
> Thanks a lot for your feedback.
> 
> 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. 
> 
> This is our attempt to provide vector programming to Java users with efficient tight back-end code generation.
> 
> Quoting John Rose from one of the panama-dev posts:
> "This is a good time to talk about where the Vector API
> might go in the future, and how we are trying to get there.
> The short answer is, a long way in small steps.
> Getting any kind of tight vector code from Java is a major
> accomplishment all by itself, whether the code is shape
> agnostic or not.  Removing shape dependencies has always
> been on the roadmap, but we have to start somewhere	
> more concrete.  As you point out, shape-aware code will
> probably always be a use case.  I don't think we will get
> stuck there, and I look forward, after a few more rounds
> with shape-aware code, to working on the problems of
> shape-shifting (shape polymorphic) loops."
> 
> You might also be interested in ARM SVE related post by Paul Sandoz on panama-dev mailing list archives.
> http://mail.openjdk.java.net/pipermail/panama-dev/2018-March/001199.html
> 
> 
> Best Regards,
> Sandhya
> 
> -----Original Message-----
> From: Ningsheng Jian [mailto:ningsheng.jian at linaro.org] 
> Sent: Tuesday, April 10, 2018 1:02 AM
> To: Viswanathan, Sandhya <sandhya.viswanathan at intel.com>
> Cc: jdk-dev at openjdk.java.net; John Rose <john.r.rose at oracle.com>; Vladimir Ivanov <vladimir.x.ivanov at oracle.com>; Aundhe, Shirish <shirish.aundhe at intel.com>; Lupusoru, Razvan A <razvan.a.lupusoru at intel.com>
> Subject: Re: Draft JEP: Vector API
> 
> Hi Sandhya,
> 
> Thanks for taking into account ARM SVE!
> 
> From the description, you've mentioned that we just need to get
> preferred species by API instead of the hardcoded concrete vector
> shape. That's really good. But I just checked current VectorAPI code.
> There are only 64, 128, 256 and 512 bit vector shapes. Regarding to
> SVE's vector length agnostic feature, do you have a plan to extend
> current vector shapes, e.g. introducing some kind of Agnostic shape?
> 
> Thanks,
> Ningsheng
> 
> On 10 April 2018 at 01:49, Viswanathan, Sandhya
> <sandhya.viswanathan at intel.com> wrote:
>> 
>> 
>> This draft JEP contains a proposal to provide an incubating module to express vector computations in Java that reliably compiles at runtime to optimal vector hardware instructions on supported CPU architectures and thus achieve superior performance than equivalent scalar computations.
>> 
>> 
>> For more details, please see:
>> https://bugs.openjdk.java.net/browse/JDK-8201271
>> 
>> Best Regards,
>> Sandhya
>> 
>> 
> 
> 
> 
> -- 
> Ningsheng