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

[Viswanathan, Sandhya]

Hi Andrew,

Intel has a long history of contributing to Java and being part of OpenJDK. 
We have always responded to bug reports and supported the code that we contribute.
This shouldn’t be any different.

Best Regards,
Sandhya

-----Original Message-----
From: Andrew Dinn <adinn at redhat.com> 
Sent: Thursday, May 20, 2021 4:03 AM
To: Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; Andrew Haley <aph at redhat.com>; 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

Hi Sandhya,

On 20/05/2021 00:51, Viswanathan, Sandhya wrote:
> 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.
I appreciate the above explanation and am largely swayed by the argument that this is a useful, albeit expedient, way forward. Thank you for pinpointing the goal here.

Could you clarify one important detail. Is the original C code (with compiler-specific vector extensions) able to be made available either as open source or using some other form of licensing.

I ask because I think it would significantly lower the risk I feel is present in importing this code if OpenJDK devs were able to see the source functions from which the various machine code routines have been derived and understand the algorithms that they embody.

Without that sort of understanding I can see this becoming a bug trap where a report of a vector floating point computation that goes awry may well leave whoever is left to debug the problem with no clear way of ruling out a problem in the vector code, most especially wasting a lot of time trying to do so before looking elsewhere for a more likely/obvious error.

Of course, the situation is not necessarily a lot better with the source available; generated machine code is clearly not going to be easily mapped back to C code. Still, I'd prefer it if OpenJDK devs had a fighting chance than little or none.

regards,


Andrew Dinn
-----------
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill