RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics

[Viswanathan, Sandhya]

Hi Andrew,

Sorry for delay in response.
The code contributed here is from Intel SVML which is shipped with Intel C compiler.
The origin of SVML goes back to early 2000s and is well tested.
The routines contributed to OpenJDK are high accuracy (within 1ulp) routines.
The library is written using Intel C Compiler extensions.
The generated code is the only way we could bring it in.
Our collective goal is to bring SIMD programming to Java application writers. 
Due to lack of SIMD programming capability in Java, compute intensive applications originally written in Java are looking to move to native or other languages in future.
As part of Vector API incubation, we want to give a platform to application writers where they can experiment writing their data-parallel algorithms in Java itself.
We hope that bringing generated assembly like this is one off as you mention and not something to become a practice. 

Best Regards,
Sandhya

-----Original Message-----
From: hotspot-compiler-dev <hotspot-compiler-dev-retn at openjdk.java.net> On Behalf Of Andrew Haley
Sent: Wednesday, May 19, 2021 1:48 AM
To: Paul Sandoz <paul.sandoz at oracle.com>
Cc: hotspot compiler <hotspot-compiler-dev at openjdk.java.net>
Subject: Re: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics

On 5/17/21 6:51 PM, Paul Sandoz wrote:
> I’ll let Sandhya talk more about the provenance and numerical accuracy. I think we can add more comments/details in that respect.
> 
> IMO this is a reasonable compromise, at least for incubation with follow on investigation to determine if we can leverage possible enhancements to Panama FFM (see JEP 414 section on SVML). We would like encourage experimentation of numerical data-parallel algorithms. The performance gains using SVML are compelling in that regard.

I understand the argument from utility here, but it's a very substantial precedent to take. In the licence we use for OpenJDK, the "source code" for a work means the preferred form of the work for making modifications to it.
This is not the preferred form. These assembly-code files are not much more use than binary blobs would be. They are a black box.

(I'm aware that we've had a few of these from Intel before, but ISTM that this is a much bigger deal.)

I understand that permission to include these files was probably granted as a result of negotiations with Intel. And it's great to have this code in OpenJDK.

However, I am sure that no-one on this project looks forward to a future in which part of our "source code" consists of what are in effect unfixable binary blobs. We should at least have the conversation about whether this is the way OpenJDK should be going.

--
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com> https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671