[vector]About Graceful degradation feature in JEP 414

[Paul Sandoz]

> On Jul 25, 2021, at 8:47 PM, Wang Zhuo(Zhuoren) <zhuoren.wz at alibaba-inc.com> wrote:
> 
> Thank you Paul. 
> I still have some questions.
> 1. Since we have not put any effort into an performant solution for graceful degradation, is it better to print warnings when intrinsic failures happen?

We have put some effort in, it's functional, but we just have not focused as much on this area. Warnings could be useful. FWIW we have them enabled in debug builds when
-XX:+PrintIntrinsics is set.

First I would like to get to the point at which we have filled in all the operational gaps, then step back and assess.


> 2.About Platform agnostic. I am not clear with the goal of Platform agnostic, because current APIs are already architecture independent. What will the Platform agnostic feature bring to us?
> 

It allows one to write shape independent (independent of vector length) computations, across multiple CPU architectures. You might be attributing more to my comments on cases where it may be necessary to query CPU properties :-) My hope is for the majority of cases a developer can write their SIMD data parallel algorithm once, the API has been designed for that, but perhaps there are edge cases. It would be good to find out.

Paul.

> Regards,
> Zhuoren
> 
> ------------------------------------------------------------------
> From:Paul Sandoz <paul.sandoz at oracle.com>
> Sent At:2021 Jul. 22 (Thu.) 23:37
> To:Sandler <zhuoren.wz at alibaba-inc.com>
> Cc:panama-dev <panama-dev at openjdk.java.net>
> Subject:Re: [vector]About Graceful degradation feature in JEP 414
> 
> Hi Zhuoren,
> 
> Each vector operation goes through an intrinsic method. If a call to such a method cannot be intrinsified, such as when there is no suitable hardware instruction, then it falls back to the pure Java implementation. The last parameter of the intrinsic is a lambda that provides the pure Java implementation, and the intrinsic method body calls that lambda.
> 
> It’s sort of “graceful” :-) but its not as performant as I would like. Ideally it should be as performant as equivalent scalar code, that is optimizable by the auto-vectorizer. That is not currently the case and we have not put any effort into this area as of now.
> 
> —
> 
> One area developers struggle with is determining “does this vector expression optimize?”. In part this is because not all operations were made intrinsic, but we have made good progress filling in the gaps on x64 and ARM. There are still a few operational gaps left, and there are a few gaps left with regards to composition of methods with vector parameters and ensuring vector instances are not boxed (I hope in the latter two cases Project Valhalla will help consolidate and improve on those areas). 
> 
> We have not yet added a way to query what operations might be intrinsic, or say a way to get more details of the CPU properties. The API is designed such that a developer can write their algorithm without depending on the vector size. However, there might be cases that require slightly different expressions of the algorithm based on the CPU architecture.
> 
> Paul.
> 
> > On Jul 22, 2021, at 12:45 AM, Wang Zhuo(Zhuoren) <zhuoren.wz at alibaba-inc.com> wrote:
> > 
> > 
> > Hi, 
> > I am very interested in the Graceful degradation feature in JEP 414. We met several performance regression cases due to unsupported vector.
> > How will this feature be implemented?  Using plain instructions instead of SIMD instructions when unsupported hardware is detected, or some other approaches?
> > 
> > Regards,
> > Zhuoren
>