[VectorAPI] Enhancement of floating-point math vector API implementation
Xiaohong Gong
Xiaohong.Gong at arm.com
Thu Jan 5 06:56:21 UTC 2023
Hi Paul,
>
> > Hi Paul,
> >
> > Thanks so much for looking at the prototype!
> >
> >> We will likely need a hotspot -XX option declaring the sleef library path/name, rather than hardcoding it, that when declared enables the functionality. This is about a native external dependency that that might need to be supported for many many years. It's one reason why the SVML stubs were brought into HotSpot, but that is likely impractical for the sleef library. This will require some discussion with the HotSpot reviewers.
> >
> > The default sleef library I used in the prototype is the installed system library by distro. It could be searchable by standard shared library searching mechanism. And, yes, it's better to use a hotspot option to declare the library path/name, whose default value is the system library path.
> >
>
> The option might need to be explicitly required with no default.
>
>
> > And I totally agree that it needs some discussion regarding to the external dependency. There may be some legal issues here. We currently just choose SLEEF as an alternative for reference implementation, and we haven't spent much time to investigate its long term maintainability and stability. And we also need to know whether a such kind of third-party library is acceptable by OpenJDK. After those investigation done, I will create a PR in the jdk mainline for the further discussion.
> >
>
> Ok, be prepared for some pushback, as I don’t think it is generally acceptable for OpenJDK to have a dynamic dependency on a third-party native library, even if it is optional. Gating with a XX option may help alleviate some of those concerns. It's likely the conversation will cover similar ground when SVML source was contributed (which was a compromise because the source is in textual assembler).
Thanks so much for the advice! And I will start with the jvm option next.
Best Regards,
Xiaohong
-----Original Message-----
From: Paul Sandoz <paul.sandoz at oracle.com>
Sent: Thursday, January 5, 2023 6:00 AM
To: Xiaohong Gong <Xiaohong.Gong at arm.com>
Cc: panama-dev at openjdk.java.net; nd <nd at arm.com>
Subject: Re: [VectorAPI] Enhancement of floating-point math vector API implementation
> On Jan 4, 2023, at 12:09 AM, Xiaohong Gong <Xiaohong.Gong at arm.com> wrote:
>
> Hi Paul,
>
> Thanks so much for looking at the prototype!
>
>> We will likely need a hotspot -XX option declaring the sleef library path/name, rather than hardcoding it, that when declared enables the functionality. This is about a native external dependency that that might need to be supported for many many years. It's one reason why the SVML stubs were brought into HotSpot, but that is likely impractical for the sleef library. This will require some discussion with the HotSpot reviewers.
>
> The default sleef library I used in the prototype is the installed system library by distro. It could be searchable by standard shared library searching mechanism. And, yes, it's better to use a hotspot option to declare the library path/name, whose default value is the system library path.
>
The option might need to be explicitly required with no default.
> And I totally agree that it needs some discussion regarding to the external dependency. There may be some legal issues here. We currently just choose SLEEF as an alternative for reference implementation, and we haven't spent much time to investigate its long term maintainability and stability. And we also need to know whether a such kind of third-party library is acceptable by OpenJDK. After those investigation done, I will create a PR in the jdk mainline for the further discussion.
>
Ok, be prepared for some pushback, as I don’t think it is generally acceptable for OpenJDK to have a dynamic dependency on a third-party native library, even if it is optional. Gating with a XX option may help alleviate some of those concerns. It's likely the conversation will cover similar ground when SVML source was contributed (which was a compromise because the source is in textual assembler).
Paul.
More information about the panama-dev
mailing list