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-r...@openjdk.org> On Behalf Of Vladimir > Ivanov > Sent: Thursday, December 12, 2024 4:09 AM > To: Paul Sandoz <paul.san...@oracle.com> > Cc: hotspot-compiler-...@openjdk.org; panama-...@openjdk.org; core- > libs-dev <core-libs-dev@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
