On Mon, 6 Feb 2023 11:56:22 GMT, Eirik Bjorsnos <d...@openjdk.org> wrote:
>> src/java.base/share/classes/java/lang/System.java line 2671: >> >>> 2669: if (false) { >>> 2670: // Arrays.mismatch without the range checks (~5% >>> faster micro getEntryHit) >>> 2671: int aLength = encoded.length; >> >> Part of the difference you're seeing is due to knowing that you'll be >> matching the entire length of the first array (`encoded, 0, encoded.length`). >> >> As an experiment I added `Arrays.mismatch(byte[], byte[], int, int)` to >> mismatch the entire range of the first array argument vs the range of the >> second and can spot an improvement in affected micros: >> >> Benchmark (size) Mode Cnt Score >> Error Units >> ArraysMismatch.Char.differentSubrangeMatches 90 avgt 10 12.165 ± >> 0.074 ns/op # mismatch(a, aFrom, aTo, b, bFrom, bTo) >> ArraysMismatch.Char.subrangeMatches 90 avgt 10 10.748 ± >> 0.006 ns/op # mismatch(a, b, bFrom, bTo) >> >> This might be something we can solve in the JITs without having to add new >> methods to `java.util.Arrays` to deal as efficiently as possible with the >> case when we're matching against the entirety of one of the arrays. > > Interesting. Would be nice to solve this in the JIT! > > This disabled code got deleted in my last commit, but it seems like you have > a good analysis so we can let it go now. Right. I might have fumbled this experiment a bit, and perhaps your setup would inline and then eliminate some of the known-in-range checks already. Though we have intrinsified some of the `Preconditions.check*` methods in the past to help improve range checks, but the `checkFromToIndex` method that would be applicable here has not been intrinsified. It might be a reasonable path forward to replace `Arrays.rangeCheck` with `Preconditions.checkFromToIndex` and then look at intrinsifying that method to help eliminating or optimizing some of the checks. ------------- PR: https://git.openjdk.org/jdk/pull/12290