Draft JEP: Vector API

[Ningsheng Jian]

Hi Sandhya,

Thanks for the explanation.

On 12 April 2018 at 06:48, 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.

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.

>
> 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
>

Thanks for pointing this out. You've already done a lot of good work
on Vector API!

Regards,
Ningsheng