Vector API reproducibility bug (?)

[Paul Sandoz]

> 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