module support

[uhoefel]

Currently I get the following error trying to use both LAPACK and BLAS in my project:

The relevant piece from my module-info:

    requires lapack;
    requires arpack.combined.all;
    requires blas;

(ARPACK is necessary for the intW type needed e.g. for dpotf2)

my pom.xml:

<dependency>
  <groupId>dev.ludovic.netlib</groupId>
  <artifactId>lapack</artifactId>
  <version>2.2.1</version>
</dependency>
<dependency>
  <groupId>dev.ludovic.netlib</groupId>
  <artifactId>arpack</artifactId>
  <version>2.2.1</version>
</dependency>
<dependency>
  <groupId>dev.ludovic.netlib</groupId>
  <artifactId>blas</artifactId>
  <version>2.2.1</version>
</dependency>

I think this can be fixed by adding module support, which would also remove the warning coming with the packages at the moment:

[luhenry]

Hi @uhoefel. As the error indicates, dev.ludovic.netlib is currently using a split package approach: the dev.ludovic.netlib package is defined in multiple artifacts. Unfortunately, that seems to be incompatible with modules...

Changing that API would imply an API breakage, as it would need to move dev.ludovic.netlib.BLAS, dev.ludovic.netlib.LAPACK, dev.ludovic.netlib.ARPACK, and all the other dev.ludovic.netlib.* classes into their respective dev.ludovic.netlib.blas, dev.ludovic.netlib.lapack, and dev.ludovic.netlib.arpack packages.

Which version of the JDK is that currently blocking you on?

[uhoefel]

I use java 17:

openjdk 17.0.1 2021-10-19
OpenJDK Runtime Environment GraalVM CE 21.3.0 (build 17.0.1+12-jvmci-21.3-b05)
OpenJDK 64-Bit Server VM GraalVM CE 21.3.0 (build 17.0.1+12-jvmci-21.3-b05, mixed mode, sharing)

and I use modules in my project.

[jonathanschilling]

Hi @luhenry,

I am working with @uhoefel and strongly support to migrate our codebase
(which currently still relies on the ancient fommil/netlib-java) to this project.
It is the right time now to fix this issue, since this project is not so widely used yet.

It would be awesome if there would be a Java package providing BLAS and LAPACK using the Java Vector API
and I think this project could be the one.
However, if this issue is not fixed before more people start using this project,
this might significantly limit usability in the future when the Java module system
will have become more mandatory to use.

What do you think?

[luhenry]

@jonathanschilling I agree with your take. I will try to give it some time in the coming weeks. I also welcome any contribution, and would be very happy to integrate your changes to support module. I can then take care of updating its usage in Spark to match the change of API.

Also, this package has a BLAS implementation using the Vector API at https://github.com/luhenry/netlib/blob/master/blas/src/main/java/dev/ludovic/netlib/blas/VectorBLAS.java. There isn't any LAPACK implementation since the surface is so much larger.

The major performance blocker while using the Vector API was limitations in the register allocator which would lead to register spilling leading to not-optimal performance (max ~16Gflops vs ~22Gflops with OpenBLAS). Without this register spilling, the GEMM would be on-par performance wise between the Vector API and OpenBLAS/Intel MKL.

[luhenry]

This has been fixed with https://github.com/luhenry/netlib/releases/tag/v3.0.0

[jonathanschilling]

Thanks a lot for resolving this issue! 👍