On Fri, 1 Dec 2023 08:48:52 GMT, Xiaohong Gong <xg...@openjdk.org> wrote:
>> Currently the vector floating-point math APIs like >> `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, >> which causes large performance gap on AArch64. Note that those APIs are >> optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. >> To close the gap, we would like to optimize these APIs for AArch64 by >> calling a third-party vector library called libsleef [2], which are >> available in mainstream Linux distros (e.g. [3] [4]). >> >> SLEEF supports multiple accuracies. To match Vector API's requirement and >> implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA >> instructions used stubs in libsleef for most of the operations by default, >> and 2) add the vector calling convention to apply with the runtime calls to >> stub code in libsleef. Note that for those APIs that libsleef does not >> support 1.0 ULP, we choose 0.5 ULP instead. >> >> To help loading the expected libsleef library, this patch also adds an >> experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. >> People can use it to denote the libsleef path/name explicitly. By default, >> it points to the system installed library. If the library does not exist or >> the dynamic loading of it in runtime fails, the math vector ops will >> fall-back to use the default scalar version without error. But a warning is >> printed out if people specifies a nonexistent library explicitly. >> >> Note that this is a part of the original proposed patch in panama-dev [5], >> just with some initial review comments addressed. And now we'd like to get >> some wider feedbacks from more hotspot experts. >> >> [1] https://github.com/openjdk/jdk/pull/3638 >> [2] https://sleef.org/ >> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/ >> [4] https://packages.debian.org/bookworm/libsleef3 >> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html > > Xiaohong Gong has updated the pull request with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains ten additional > commits since the last revision: > > - Separate neon and sve functions into two source files > - Merge branch 'jdk:master' into JDK-8312425 > - Rename vmath to sleef in configure > - Address review comments in build system > - Add a bundled native lib in jdk as a bridge to libsleef > - Merge 'jdk:master' into JDK-8312425 > - Disable sleef by default > - Merge 'jdk:master' into JDK-8312425 > - 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF Let me summarize the issues, as I see them: To a high-order approximation, no one builds their own JDK. We want people to be able to use these vector math operations. There is no need to depend on a specific SLEEF library version. I do not expect SLEEF to break the ABI by e.g. renaming functions. (I know, but let's assume.) As long as the functions we want to use are present, we should use them. SLEEF is not (yet) a standard part of OSs and build systems. We don't want to fail unnecessarily at runtime because of a SLEEF ABI version change. We don't want to fail to build the JDK if our GCC is too old for SVE. (Is that a problem now? It might be.) We want to be able to test and run with any version of SLEEF, as long as the functions we need are present. It should be possible to drop a SLEEF library into the system, and the JDK will use it. The alternative is to package SLEEF with the JDK. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1835829658
