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

[Dietmar Lippold]

> Remi Forax <forax at univ-mlv.fr> hat am 04.04.2022 00:00 geschrieben:
> 
>  
> ----- Original Message -----

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

Hi Rémi,

thanks for the hint. I think the parallelization (here by shared memory among several cores) and the vectorization are independent techniques for processing arrays, i.e. only one of them can be used or they can be used together. My implementation only uses vectorization by using the classes of this project, in particular it does not use fork-join processing (unfortunately the classes I attached to my mail were not forwarded by pipermail to the mailing list).

Do you know of investigations in which cases the fine grained parallelism of ParallelArray results in a speedup (e.g. kind of operation, length of vectors, speed of memory subsystem). At least for GPUs the parallelization should be useful or even important. But using GPUs in Java are a different thing.

In principle a common API for vectorization and parallelization would be great I think.

Dietmar