[foreign] Pointer to fixed-size array: is jexctract's mapping to Java correct?

[Lev Serebryakov]

On 28.02.2019 0:18, Maurizio Cimadamore wrote:

> So, let me make sure I understand what you are saying:
> 
> 1) the API takes a pointer-to-array-of-double
  Yes.

> 2) In reality this means, I want one or more double pairs (where
> emphasis is on the 'more' side of things)
  Yes. And it is typical layout for data used in such tasks, as Fast
Fourier Transform — one buffer, with interleaving real and imaginary
parts of complex numbers.

> 3) In C, you would just allocate a big slab of memory, big enough to
> hold the data you need, and fill it accordingly (with all the pairs).
> Then you pass the pointer to the API and you rely on C loose pointer vs.
> array semantics
  Yep. It is how this API is intended to be used and used all around the
world. Think like BLAS API, which is used as example in Panama
(https://hg.openjdk.java.net/panama/dev/raw-file/6b1f1666f5f6/doc/panama_foreign.html)

 BLAS API to multiply complex vectors is even worse, it uses `void*`
(!!!) to represent array of complex numbers:

void cblas_cgemv(const enum CBLAS_ORDER order,
     const enum CBLAS_TRANSPOSE TransA, const int M, const int N,
     const void *alpha, const void *A, const int lda,
     const void *X, const int incX, const void *beta,
     void *Y, const int incY);

> 4) The fact that Panama is stricter and it models the signature as
> Pointer<Array<Double>> is correct, but inconvenient, as now, to call the
> function, you have to create many Arrays (one for each pair) - that is,
> it seems less flat that what the C code does - something like:
> 
> 
> int N = 200; //number of complex pairs
> try (Scope s = Scope.globalScope().fork()) {
>    Array<Array<Double>> pairs =
> s.allocateArray(NativeTypes.DOUBLE.array(2), N);
>    for (int i = 0 ; i < N ; i++) {
>        pairs.set(i, s.allocateArray(NativeTypes.DOUBLE, new double[] {
> d1, d2 }); // replace d1 and d2 with actual data
>    }
> 
>    ...
> 
>    Pointer<Array<Double>> pairs_ptr = pairs.elementPointer();
> 
> }
> Am I right that your discomfort comes from having to allocate all those
> native arrays? (which will then copied in the destination pair array)
 Yep. And copy data from "java native" array and back. It will dominate
execution time for small transform sizes, I'm afraid — copying from
native Java array to these pairs. Performance-wise, best solution will
be to have `Array<Double>` transparently backed by `double[]`, it will
mimic C code as close as possibly (and as fast as possibly).

 But I need to finish benchmarks to see how much CPU will be spent on
data preparation.

-- 
// Black Lion AKA Lev Serebryakov