About JEP 338: Vector API

[Adam Pocock]

Hi Bruno,

The model you’re proposing could be built on top of the Vector API as a library. The current API is lower level but provides much more power than the approach you are describing, as it allows things to be expressed which could not be autovectorised by a compiler. The design point is more similar to SIMD intrinsics in C, though more abstracted away from the hardware. SIMD computation isn’t just mapping a function across a tuple of arrays to produce another array, and the current API reflects that.

It’s possible to express complex ML algorithms as SPMD computations using the Vector API, and if it was reduced to a function mapped over arrays it would be difficult to do the same as there is no way to have vector registers persist while other computation happens.

Thanks,

Adam
--
Adam Pocock
Principle Member of Technical Staff
Machine Learning Research Group
Oracle Labs, Burlington MA

> On 9 Feb 2021, at 05:47, b.lacombe at lug.com wrote:
> 
> Hello Paul,
> 
> Yes solution 3, is very complexe and you proposition with lambda is 
> complexe (I like).
> 
> But my point (2) (with cache, and forEach operator) is less expensive to 
> implement and offer a easy way to simplify  code.
> I think it 'll be a good compromise for a first solutions.
> Why I insist : it 's because more people think java is complex, and if we 
> offer new API withe complexity to write, We give the stick to fight us (ie 
> in French: "Nous donnons le bâton pour nous battre")
> 
> 
> Bruno
> 
> 
> 
> From:   "Paul Sandoz" <paul.sandoz at oracle.com>
> To:     "b.lacombe at lug.com" <b.lacombe at lug.com>
> Cc:     "panama-dev at openjdk.java.net'" <panama-dev at openjdk.java.net>
> Date:   09/02/2021 00:11
> Subject:        Re: About JEP 338: Vector API
> 
> 
> 
> Hi Bruno,
> 
> You make a fair point about the complexity. The API is designed to be 
> low-level and literal, making use of current language features, requiring 
> a vector expression be built as an explicit tree (as if input to a 
> compiler).
> 
> It would be interesting to express:
> 
>  DoubleVector va = ...
>  DoubleVector vb = ...
>  DoubleVector vc = va.lanewise(vb, (double a, double b) -> -(a*b + b*b));
> 
> Whereby the Vector API can reflect over the scalar code of the lambda 
> expression. Then potentially use the same expression to operate over two 
> arrays, the implementation of which may utilize the same expression for 
> fixed length vectors over the variable length arrays.
> 
> It is a non-trivial exercise (an understatement!) to modify the Java 
> language and runtime in such a manner, but something like the above is 
> what we have mused about before, and I think is a promising approach.
> 
> Paul.
> 
> 
>> On Feb 5, 2021, at 6:19 AM, b.lacombe at lug.com wrote:
>> 
>> About JEP 338: Vector API
>> 
>> A)  you write :
>> -----
>> static final VectorSpecies<Float> SPECIES = FloatVector.SPECIES_256;
>> 
>> void vectorComputation(float[] a, float[] b, float[] c) {
>> 
>> 
>>   for (int i = 0; i < a.length; i += SPECIES.length()) {
>>       var m = SPECIES.indexInRange(i, a.length);
>>   // FloatVector va, vb, vc;
>>       var va = FloatVector.fromArray(SPECIES, a, i, m);
>>       var vb = FloatVector.fromArray(SPECIES, b, i, m);
>>       var vc = va.mul(va).
>>                   add(vb.mul(vb)).
>>                   neg();
>>       vc.intoArray(c, i, m);
>>   }
>> }
>> -----
>> It is very complexe source code to write a simple (a*a+b )*-1
>> 
>> It 'll more easy, if we can write :
>>       FloatVector.forAll(a).mul(a).add(b).neg().toArray(c)
>> Where each operator (mul,add,neg) can make the convertion :
>>       var va=>FloatVector.fromArray(SPECIES, a, i, m) ...
>> Of course optimisation can be done  with a code like :
>> ----
>>       void mul(a, ... buf){
>>               var va = cache.get(a);
>>               if( va==nul ){
>>                       va =  FloatVector.fromArray(SPECIES, a, i, m);
>>                       cache.put(a,va);
>>               }
>>               //here va
>>               .....
>>       }
>> ----
>> 
>> 2) A another optimisation can be make by preparing data  whith a "width" 
> 
>> operator like :
>>       FloatVector
>>               .width(a,b,c)
>>               .forAll(a)
>>               .mul(a).add(b).neg()
>>               .toArray(c);
>> then source is more easy to read, and less complex 
>> what did you think ?
>> 
>> 
>> 3) And if we can upgrade java grammar, a code like this for matrix :
>>               c = FloatVector[[ a*a+b*-1 ]] 
>> would be ecxellent (where a,b,c must be final array) and so easy ....
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Cordialement
>> 
>> Bruno LACOMBE
>> Multimédia SOLUTIONS
>> Site Technologique de Marticot
>> 33610 Cestas
>> Tel (33) 05.56.21.51.18
>> Téléchargez Windex GED : Gestion Electronique de Documents
>> http://www.lug.com
> 
> 
> 
>