[Vector API] Why to talk about lanes, shapes and species in the API doc?

Sun Apr 3 22:00:07 UTC 2022

----- Original Message -----
> From: "Dietmar Lippold" <dietmar.lippold at mailbox.org>
> To: "Paul Sandoz" <paul.sandoz at oracle.com>, "August Nagro" <augustnagro at gmail.com>
> Cc: "panama-dev at openjdk.java.net'" <panama-dev at openjdk.java.net>
> Sent: Sunday, April 3, 2022 11:22:59 PM
> Subject: Re: [Vector API] Why to talk about lanes, shapes and species in the API doc?

> Hi Paul, hi August,
> 
> thanks for your positive answers. Attached I send such an partial implementation
> of a higher-level class which uses IntVector (named "HighLevelIntVector"), as
> well as a superclass ("HighLevelVector") and a test class ("HighLevelTest").
> These belong to a package named "hlvector". The test class contains the
> following method:
> 
>    public static int[] intVectorComputation(int[] a, int[] b) {
> 
>        var va = HighLevelIntVector.fromArray(a);
>        var vb = HighLevelIntVector.fromArray(b);
>        var vc = va.mul(va)
>                   .add(vb.mul(vb))
>                   .neg();
> 
>        return vc.toArray();
>    }
> 
> What do you think about these classes?

This is more or less the ParallelArray API that Doug Lea proposes several years ago.
Does your implementation also mix the fork-join processing and the Vectorized API ?

> 
> Dietmar

Rémi

> 
> 
>> Paul Sandoz <paul.sandoz at oracle.com> hat am 01.04.2022 02:00 geschrieben:
>> 
>>  
>> Hi Dietmar,
>> 
>> I think what might be useful exploration is a higher-level API whose
>> implementation uses the Vector API. Vector API will remain focused on specific
>> shapes (perhaps expanding from the current set into small groups of vectors).
>> 
>> —
>> 
>> On specific sized species, an example might be casting from byte to int, so
>> loading 8 bytes in a 64 bits and casting to 8 ints in a 256 bits e.g. for
>> computing the hash code of a byte[] array. The alternative is to operate on the
>> four parts of 32 bytes in 256 bits.
>> 
>> Paul.
>> 
>> > On Mar 31, 2022, at 2:28 PM, Dietmar Lippold <dietmar.lippold at mailbox.org>
>> > wrote:
>> > 
>> > Hi Paul,
>> > 
>> > I'm enthused that such a higher level API shall be explored. I think it could
>> > also be useful for the design of the current lower level API. E.g. the usage of
>> > predicate registers and even more the enhancement of the C2 compiler to save
>> > the additional processing of the tail elements (as described below the cited
>> > example code on the JEP 417 page) may not be necessary anymore because the
>> > additional processing is hidden in the higher level library.
>> > 
>> > I could write and provide an example implementation of the higher level API. Is
>> > that desired? If yes, could I send the classes as attachments to this mailing
>> > list or how should I provide the classes?
>> > 
>> > Could it be reasonable not to use the SPECIES_PREFERRED (e.g.
>> > FloatVector.SPECIES_PREFERRED), i.e. to use a different shape? If yes, in which
>> > situations?
>> > 
>> > Dietmar
>> > 
>> > 
>> >> Paul Sandoz <paul.sandoz at oracle.com> hat am 30.03.2022 21:37 geschrieben:
>> >> 
>> >> 
>> >> Hi Dietmar,
>> >> 
>> >> I think you have misunderstood the intent of the Vector API.
>> >> 
>> >> The Vector API uses the term vector as in vector hardware register, whose size
>> >> is a fixed number of bits (shape), and can be viewed as a fixed-sized array of
>> >> primitive values (species). The API is specifically designed such that an
>> >> instance of Vector compiles down to a value in a vector register, and
>> >> operations compile down to one or a few vector hardware instructions. I
>> >> sometimes refer to this API as a What You See Is What You Get (WYSIWYG) API.
>> >> 
>> >> What you desire, quite reasonably, is a higher level abstraction to operate over
>> >> variable length arrays. The chosen parallel mechanism would be an
>> >> implementation detail of such an abstraction. This kind of abstraction also
>> >> makes sense for matrices or tensors. We do want to explore such APIs in the
>> >> platform, but IMO we would first need to identify/propose enhancements to
>> >> language so we can design the array-like API that we would be comfortable
>> >> proposing and supporting. (Note some enhancements make come with Project
>> >> Valhalla we likely require more.)
>> >> 
>> >> —
>> >> 
>> >> Providing a link to the relevant area of the release JavaDoc (once available)
>> >> seems reasonable. It’s not something we have generally done with appropriate
>> >> JEPs, but I think it’s useful.
>> >> 
>> >> Paul.
>> >> 
>> >>> On Mar 29, 2022, at 11:41 AM, Dietmar Lippold <dietmar.lippold at mailbox.org>
>> >>> wrote:
>> >>> 
>> >>> Hi,
>> >>> 
>> >>> why is it necessary to talk about "lanes", "shapes" and "species" in the API
>> >>> doc?  From my point of view a Vector should be similar to an array, in
>> >>> particular it could have an arbitrary number of _elements_ (up to
>> >>> Integer.MAX_VALUE) and it should not be necessary to know something about the
>> >>> hardware (CPU or GPU).
>> >>> 
>> >>> On the page of JEP 417 (https://openjdk.java.net/jeps/417) there is the code:
>> >>> 
>> >>> static final VectorSpecies<Float> SPECIES = FloatVector.SPECIES_PREFERRED;
>> >>> 
>> >>> void vectorComputation(float[] a, float[] b, float[] c) {
>> >>>     int i = 0;
>> >>>     int upperBound = SPECIES.loopBound(a.length);
>> >>>     for (; i < upperBound; i += SPECIES.length()) {
>> >>>         // FloatVector va, vb, vc;
>> >>>         var va = FloatVector.fromArray(SPECIES, a, i);
>> >>>         var vb = FloatVector.fromArray(SPECIES, b, i);
>> >>>         var vc = va.mul(va)
>> >>>                    .add(vb.mul(vb))
>> >>>                    .neg();
>> >>>         vc.intoArray(c, i);
>> >>>     }
>> >>>     for (; i < a.length; i++) {
>> >>>         c[i] = (a[i] * a[i] + b[i] * b[i]) * -1.0f;
>> >>>     }
>> >>> }
>> >>> 
>> >>> It should be possible to write instead:
>> >>> 
>> >>> void vectorComputation(float[] a, float[] b, float[] c) {
>> >>>     // FloatVector va, vb, vc;
>> >>>     var va = FloatVector.fromArray(a);
>> >>>     var vb = FloatVector.fromArray(b);
>> >>>     var vc = va.mul(va)
>> >>>                .add(vb.mul(vb))
>> >>>                .neg();
>> >>>     vc.intoArray(c);
>> >>> }
>> >>> 
>> >>> To make that possible the current class Vector (as well as its subclasses) could
>> >>> be converted into an inner class VectorHelp (or named similar) and that could
>> >>> handle all things of lanes, shapes and species.
>> >>> 
>> >>> Btw: Please add a link to the API doc of the Vector package
>> >>> (https://docs.oracle.com/en/java/javase/18/docs/api/jdk.incubator.vector/jdk/incubator/vector/package-summary.html)
>> >>> to the page of the JEP 417 (https://openjdk.java.net/jeps/417).
>> >>> 
> > >>> Dietmar