RFR: 8328138: Optimize ArrayEquals on AArch64 & fix potential crash
Andrew Haley
aph at openjdk.org
Fri Mar 15 09:53:37 UTC 2024
On Thu, 14 Mar 2024 06:21:56 GMT, Xiaowei Lu <duke at openjdk.org> wrote:
> Current implementation of ArrayEquals on AArch64 is quite complex, due to the variety of checks about alignment, tail processing, bus locking and so on. However, Modern Arm processors have eased such worries. Besides, we found crash when using lilliput. So we proposed to use a simple&straightforward flow of ArrayEquals.
> With this simplified ArrayEquals, we observed performance gains on the latest arm platforms(Neoverse N1&N2)
> Test case: org.openjdk.bench.java.util.ArraysEquals
>
> 1x vector length, 64-bit aligned array[0]
> | Test Case | N1 | N2 |
> |:----------------------:|:---------:|:---------:|
> | testByteFalseBeginning | -21.42% | -13.37% |
> | testByteFalseEnd | 25.79% | 27.45% |
> | testByteFalseMid | 16.64% | 16.46% |
> | testByteTrue | 12.39% | 24.66% |
> | testCharFalseBeginning | -5.27% | -3.08% |
> | testCharFalseEnd | 29.29% | 35.23% |
> | testCharFalseMid | 15.13% | 19.34% |
> | testCharTrue | 21.63% | 33.73% |
> | Total | 11.77% | 17.55% |
>
> A key factor is to decide when we should utilize simd in array equals. An aggressive choice is to enable simd as long as array length exceeds vector length(8 words). The corresponding result is shown above, from which we can see performance regression in both testBeginning cases. To avoid such perf impact, we can set simd threshold to 3x vector length.
>
> 3x vector length, 64-bit aligned array[0]
> | | n1 | n2 |
> |:----------------------:|:---------:|:---------:|
> | testByteFalseBeginning | 8.28% | 8.64% |
> | testByteFalseEnd | 6.38% | 12.29% |
> | testByteFalseMid | 6.17% | 7.96% |
> | testByteTrue | -10.08% | 3.06% |
> | testCharFalseBeginning | -1.42% | 7.23% |
> | testCharFalseEnd | 4.05% | 13.48% |
> | testCharFalseMid | 8.79% | 16.96% |
> | testCharTrue | -5.66% | 10.23% |
> | Total | 2.06% | 9.98% |
>
>
> In addtion to perf improvement, we propose this patch to solve alignment issues in array equals. JDK-8139457 tries to relax alignment of array elements. On the other hand, this misalignment makes it an error to read the whole last word in array equals, in case that the array doesn't occupy the whole word and lilliput is enabled. A detailed explaination quoted from [https://github.com/openjdk/jdk/pull/11044#issuecomment-1996771480](url)
>
>> The root cause is that default behavior of MacroAss...
I'm not entirely convinced this will perform better in real code.
There's a lot of conditional branches at the end, and these need only to be used in the case of a very short array.
ArraysEquals repeatedly tests the same array, leading to perfect branch prediction. In the real world this doesn't happen, so the test may be misleading.
Array comparison, in the case of anything except a very short array, can be done by a sequence of wide loads, with a single (probably misaligned) load at the end instead of that sequence of conditional branches.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/18292#issuecomment-1999300014
More information about the hotspot-dev
mailing list