About JEP 338: Vector API

[Paul Sandoz]

Hi Remi,

Thanks for pointing out it can be done using serialization, and people do that, since that is what's currently possible. I think it's problematic and we can do much better.

Paul.

On Feb 10, 2021, at 7:15 AM, Remi Forax <forax at univ-mlv.fr<mailto:forax at univ-mlv.fr>> wrote:

----- Mail original -----
De: "Paul Sandoz" <paul.sandoz at oracle.com<mailto:paul.sandoz at oracle.com>>
À: "b lacombe" <b.lacombe at lug.com<mailto:b.lacombe at lug.com>>
Cc: "panama-dev at openjdk.java.net<mailto:panama-dev at openjdk.java.net>'" <panama-dev at openjdk.java.net<mailto:panama-dev at openjdk.java.net>>
Envoyé: Mardi 9 Février 2021 00:10:57
Objet: 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.

Hi Paul,
you don't need to modify neither the language nor the JDK, using a serializable lambda should be enough.

A nice side effect of using hidden classes for the lambda proxies in jdk 16 is that now the lambda proxy and the lambda itself are nestmate so if you have a Lookup from the class that contains the lambda, you can call writeReplace on the proxy which give you the SerializedLambda object which indicates the class and method name of the lambda once desugared. Once you've got that info, you can use ASM to extract the bytecode and do an abstract interpretation of the bytecode to create the corresponding expression tree. So still some work, but less than before.


Paul.

Rémi



On Feb 5, 2021, at 6:19 AM, b.lacombe at lug.com<mailto: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
https://urldefense.com/v3/__http://www.lug.com__;!!GqivPVa7Brio!KmyZuJ0h3TpFQIlap03HvoSbCQc-2WPuT1ixHIXJzcJ8DT2heIwjNH166_CIt-ZHpQ$