RFR: 8286823: Default to UseAVX=2 on all Skylake/Cascade Lake CPUs

[Vladimir Kozlov]

On Tue, 7 Jun 2022 14:17:37 GMT, olivergillespie <duke at openjdk.java.net> wrote:

>> @olivergillespie In our analysis of mpegaudio, we found that the problem was due to auto-vectorizer kicking in for small array initialization. The auto-vectorization does not take into consideration AVX3Threshold. I have submitted a simple PR to answer your concerns https://github.com/openjdk/jdk/pull/8877. Please take a look. The PR limits the auto-vectorizer to 256-bit or 32-byte for Cascade Lake.
>
> Thanks @sviswa7 ! I don't have the expertise to evaluate your auto-vectorizer change from a theoretical standpoint. I'd like to test it out in my real applications to see if the issue you found in mpegaudio is the same issue I see on a more complex app, but unfortunately I won't be able to do that quickly (not easy to swap out JDK versions in those apps).
> 
> I'm still of the opinion that AVX3 on Cascade Lake in the JVM seems more dangerous than it's worth across the board, due to the documented inherent downclocking behaviour of that architecture. Various other SPECjvm benchmarks consistently downclock by >15%, so even if they don't show a direct performance regression with AVX3 (the improved AVX3 performance roughly balances the downclocking), they have a negative impact on other code running on the host.
> 
> It's possible your tighter change covers most of the cases in practice, which would be great, but I think this broader change still makes sense conceptually.

@olivergillespie you can test you application with `-XX:MaxVectorSize=32` product flag to see effects of #8877 changes.
Main concern about changing AVX is reduction of instructions set which could be useful.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8731