RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v4]

[Andrew Haley]

On Tue, 19 Mar 2024 17:15:29 GMT, Andrew Haley <aph at openjdk.org> wrote:

>>> If there was some kind of plan, with evidence of the intention to do something to get this valuable tech into people's hands in a form they can use, sure. But as you can tell, I think this may rot because no one will be able use it. If SLEEF were included in the JDK it'd be fine. if SLEEF were a common Linux library it'd be fine.
>>>
>>> The problem I see is that J. Random Java User has no way to know if SLEEF is making their program faster without running benchmarks. They'll put SLEEF somewhere and hope that Java uses it.
>> 
>> Please kindly correct me if I misunderstood your points.
>> Seems the safest solution to address your above concerns is to integrate the sleef source into jdk? Lack of sleef at either build time or runtime will make the user's code fall back to java implementation.
>
>> > The problem I see is that J. Random Java User has no way to know if SLEEF is making their program faster without running benchmarks. They'll put SLEEF somewhere and hope that Java uses it.
>> 
>> Please kindly correct me if I misunderstood your points. Seems the safest solution to address your above concerns is to integrate the sleef source into jdk? Lack of sleef at either build time or runtime will make the user's code fall back to java implementation.
> 
> Exactly, yes. That's why we've integrated the source code of many other libraries we depend on into the JDK. It's the only way to get the reliability our users expect.

> @theRealAph Are you saying that bundling the source code of libsleef is a hard requirement from your side to accept this code into the JDK?
> 
> I'm not against it, I just want to understand what we're talking about here.
> 
> In general, adding new libraries to OpenJDK will require a legal process in Oracle, which may (or may not) take some amount of time T, where T is larger than you'd wish for.
> 
> So I guess we can either:
> 
>     1. wait for libsleef  source code to become a part of OpenJDK, and then integrate this PR.
> 
>     2. integrate this PR optimistically, and in the background start a process of trying to get libsleef into OpenJDK. (Which, of course, can not be 100% guaranteed to happen.)

I think that's probably best the best thing to do today. I will approve it.

I'd prefer, long term, to integrate SLEEF into OpenJDK. That would make AArch64 support similar to Intel. We are competing with Intel.

In the short term, I'd build a shim library during the default standard JDK build that does not need SLEEF at build time. Unless weo do that, because SLEEF isn't on anyone's builders, it won't be used.

>     3. integrate this PR as is, and give up any idea of bundling libsleef.
> 
> 
> I also believe there is a fourth option, but that too seems like it has legal implications that needs to be checked:
> 
>     4. if the libsleef dynamic library is found on the system during build time, bundle a copy of the dll with the built JDK. (Similar to how was done with freetype on Windows before.). And, optionally, provide an option for configure to require libsleef to be present, so the build fails if no libsleef can be found and bundled. (Leaving open as to if this should be default or not.)

Ewww. No. :-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18294#issuecomment-2012798235