RFC: Untangle native libraries and the JVM: SVML, SLEEF, and libsimdsort

[Bhateja, Jatin]

Hi Vladimir,

This looks good, I recall we discussed a similar topic on panama-dev mailing list [1] to give Java developers a handle to write custom target-specific logic. The approach is identical to .NET hardware intrinsics[2] though in this case, we deal in higher-level target-specific intrinsics rather than operating at the instruction level.

Best Regards,
Jatin 

[1] https://mail.openjdk.org/pipermail/panama-dev/2024-June/020493.html 
[1] https://devblogs.microsoft.com/dotnet/dotnet-8-hardware-intrinsics/


> -----Original Message-----
> From: panama-dev <panama-dev-retn at openjdk.org> On Behalf Of Vladimir
> Ivanov
> Sent: Thursday, December 12, 2024 4:09 AM
> To: Paul Sandoz <paul.sandoz at oracle.com>
> Cc: hotspot-compiler-dev at openjdk.org; panama-dev at openjdk.org; core-
> libs-dev <core-libs-dev at openjdk.org>
> Subject: Re: RFC: Untangle native libraries and the JVM: SVML, SLEEF, and
> libsimdsort
> 
> 
> 
> >>> - There is an open bug to adjust the simd sort behavior on AMD zen 4
> cores due to poor performance of an AVX 512 instruction. The simplest
> solution is to fall back to AVX2. That may be simpler to manage in Java? (I
> was looking at the HotSpot code).
> >>
> >> For now, the patch guards AVX512 entries with VM.isIntelCPU() check. In
> order to distinguish between AMD Zen 4 and 5, either a new platform-
> sensing check is needed or reimplementation of x86-specific platform
> sensing in Java on top of CPUID info.
> >>
> >
> > Probably best just to update as required. (Also I don’t seem anything
> > in the HotSpot code to determine the AMD zen core version.)
> 
> Yes, it's not implemented yet. But there are enough examples for Intel chips
> to see how it will look like (e.g., is_intel_skylake() or is_knights_family()).
> 
> > Any general CPU vendor/model solution seems a little more challenging
> than that of surfacing up the CPU feature set as a string. Note that the
> System.getProperties() surfaces up “os.arch”. A more general solution could
> add further properties for the CPU?
> 
> Personally, I'm not a fan of "stringy" APIs. It may look convenient at first,
> but it suffers from deficiencies of both approaches. I would prefer to use a
> strongly typed platform-specific API instead (an equivalent of VM_Version
> class in hotspot).
> 
> Best regards,
> Vladimir Ivanov