Vector API reproducibility bug (?)

[Xiaohong Gong]

Thanks for the explanation @Paul Sandoz!

> > > (It may be possible to fix this difference between the interpreter and
> > > C2 for the vector operations, but it would some work to do so.)
> > > 
> >  
> > OK, do you have a plan to fix this difference?
> >  
> 
> Not currently. We would need to appeal to native methods in the vector operation fallback code.

So what should be the implementation of native methods in your mind? We may also need to consider other architectures, not just x86 (and aarch64) that I don't know what the impact would be. 

> 
> > Thinking about such kind of optimization for AArch64, I noticed that there were some questions about the code quality and maintainability of SVML assembly [1]. As John also mentioned about other possible alternatives [2], my colleague pointed me a good project, SLEEF [3], which looks promising in terms of portability, quality and performance [4]. (I don't know much about license compatibility with OpenJDK.)
> 
> That might be an option for AArch64, although like you I am unsure about license. I am confident of the code quality of the SVML assembly given it's origin.
> 
> Ideally (and I think this might have been part of the discussion) we would wire up the stubs from a library on the library path, thereby we don’t have to distribute the source with the platform (leaving open the option of how to distribute the optionally dependent library).

Yeah, I agree with you that calling the stubs from a library instead of distributing the source for each platform is a good solution. Since SVML doesn’t support other architectures, a common library that supports all architectures should be a better solution. And it will be much better and easier to maintain if a public common library can be used for ALL platforms. So I think SLEEF can be an option, even for x86. Or do we have any other candidates? 

BTW, to fix the results different issue from intrinsic and interpreter, should we use the exact same native implementation like what it calls by intrinsics in the java fallback code?

Best Regards,
Xiaohong Gong

-----Original Message-----
From: Paul Sandoz <paul.sandoz at oracle.com> 
Sent: Thursday, August 18, 2022 11:58 PM
To: Xiaohong Gong <Xiaohong.Gong at arm.com>
Cc: panama-dev at openjdk.java.net; nd <nd at arm.com>
Subject: Re: Vector API reproducibility bug (?)



> On Aug 18, 2022, at 2:54 AM, Xiaohong Gong <Xiaohong.Gong at arm.com> wrote:
> 
> > 
> > I think what you are observing for your whole project is the difference between execution of the Vector API expressions in the interpreter and execution of the optimized code produced by C2. In the former, Math::acos will be used, in the latter an SVML-derived implementation will be used.
> > 
>  
> Is this a bug that different runs on the same system may get different results?

I think it's reasonable for one to view it as such, we don’t currently specify such a difference, only a difference between the functions in Math.

>  
> > (It may be possible to fix this difference between the interpreter and
> > C2 for the vector operations, but it would some work to do so.)
> > 
>  
> OK, do you have a plan to fix this difference?
>  

Not currently. We would need to appeal to native methods in the vector operation fallback code.


> Thinking about such kind of optimization for AArch64, I noticed that there were some questions about the code quality and maintainability of SVML assembly [1]. As John also mentioned about other possible alternatives [2], my colleague pointed me a good project, SLEEF [3], which looks promising in terms of portability, quality and performance [4]. (I don't know much about license compatibility with OpenJDK.)

That might be an option for AArch64, although like you I am unsure about license. I am confident of the code quality of the SVML assembly given it's origin.

Ideally (and I think this might have been part of the discussion) we would wire up the stubs from a library on the library path, thereby we don’t have to distribute the source with the platform (leaving open the option of how to distribute the optionally dependent library).

Paul.

>  
>  
> [1] https://github.com/openjdk/jdk/pull/3638
> [2]
> https://mail.openjdk.org/pipermail/hotspot-compiler-dev/2021-May/047336.html
> [3] https://sleef.org/
> [4] https://sleef.org/benchmark.xhtml
>  
> Thanks,
> Xiaohong Gong