About JEP 338: Vector API

[b.lacombe at lug.com]

Hi Adam,

I undertand your logic and and all power of this aproach.

I regrest only that Java havn't easy way of use matrix (Vector is a way). 
then other language are more friendly to do that (but have other problems 
;-)
After this implementation maybe a lib 'll be create ...[ whith a 
free(vectore no more use ;-) ]

wait and see ... 

thanks 

Cordialement

Bruno LACOMBE



From:   "Adam Pocock" <adam.pocock at oracle.com>
To:     "b.lacombe at lug.com" <b.lacombe at lug.com>
Cc:     "Paul Sandoz" <paul.sandoz at oracle.com>, 
"panama-dev at openjdk.java.net'" <panama-dev at openjdk.java.net>
Date:   09/02/2021 16:57
Subject:        Re: About JEP 338: Vector API



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