Draft JEP: Vector API

[Lupusoru, Razvan A]

Hi Frank,

Thanks a lot for your feedback.

As you point out, the Vector API works by providing instance methods for vector operations instead of exposing static methods for the computations. The current interface is based on John Rose's Vector API strawman proposal [1] so I am hoping he can reply with some additional justification on doing it this way.

That said, I can explain why from an implementation standpoint, this works. Right now, we rely on the following properties to be able to do our translation from the API to actual vector instructions:
- Being an instance method means we can override the implementations in each of the subclasses due to polymorphism. This is important because as part of the intrinsification process we obtain various information like length and type of vector, along with information about classes for unboxing/boxing. You will see this behavior difference by taking a look at Float128Vector.java and Float256Vector.java and look at a method like "add" which shows these differences based on arguments passed to method that ends up getting intrinsified.
- Second, we rely on successful type sharpening from C2. Because type profiling is primarily enabled for receiver types (default argument profiling setting is not adequate), we use existing framework to determine appropriate vector type. This allows for inlining of the appropriate methods which in turn pulls in information needed for intrinsification as noted in first bullet point. This way we do not need a separate implementation for speculating or sharpening types. And because C2 is quite good at type sharpening, we can get good vector code without overheads of class checks.

Regarding to having a higher level API so that users do not have to worry about the details of vector programming, we agree that it makes sense. Please see Sandhya's email to Ningsheng [2].

>From my point of view, I see two key ingredients in current API that are useful as building blocks for a higher level API that automatically generates and handles things like tail processing: 1) Currently, algorithms can be written in a shape agnostic manner 2) Operations have masked variants which are useful for excluding lanes from vector computations.

Hopefully this provides some clarification. Thanks again for taking a look at our proposal.

--Razvan

-----Original Message-----
From: Frank Yuan [mailto:frank.yuan at oracle.com] 
Sent: Monday, April 09, 2018 9:05 PM
To: Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; jdk-dev at openjdk.java.net; 'John Rose' <john.r.rose at oracle.com>
Cc: '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

I read the JEP bug, and have 2 comments.


The first one is about the stream style example code. Suppose Vector API is used for math computation, the code should likely express the math concept, and look like the math formula. 

For example:
void scalarComputation(float[] a, float[] b, float[] c) {
   for (int i = 0; i < a.length; i++) { 
        c[i] = (a[i] * a[i] + b[i] * b[i]) * -1.0f;
   }
}

The proposed Vector API code is like:
Vector vc = va.
        mul(va).
        add(vb.mul(vb)).
        neg();

It's far away from the math expression: - ( va * va + vb * vb )

I would like the following code more:
Vector vc = neg(
        add(mul(va, va), mul(vb, vb)));


The second comment is that the users should not like to handle the details on the vector size, they only desire the vector computation power! We should wrap all these details, provide a high level abstract for the vector in terms of the math concept, do the loop in our private code and pad the tail.
User just say "I want vector a subtract vector b", then we give him a result.


Thanks
Frank


> -----Original Message-----
> From: jdk-dev [mailto:jdk-dev-bounces at openjdk.java.net] On Behalf Of 
> Viswanathan, Sandhya
> Subject: Draft JEP: Vector API
> 
> 
> 
> 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
>