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

[Andrew Dinn]

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