I am still working on digesting your branch. The difference in method signature is subtle, but I think a key part of the improvements you are getting. Could you add javadoc to more clearly describe how the args are to be interpreted and what the return value means?
I am playing with manually unrolling the java 8 byte-by-byte impl along with tests comparing unsafe, var handle, and vector approaches. These tests take a long time to run, so it will be a couple days before I have complete results. Do you want data as I have it (and it is interesting), or wait for summary? I am not sure when I will get opportunity to test out arm64. That could be awhile yet. I do have some things still on jdk 8, but only decompression. Surveys seem to indicate quite a bit of jdk 8 still in use, but I have no personal need. Brett On Sun, Mar 10, 2024 at 2:49 PM Lasse Collin <lasse.col...@tukaani.org> wrote: > On 2024-03-09 Brett Okken wrote: > > When I tested graviton2 (arm64) previously, Arrays.mismatch was > > better than comparing longs using a VarHandle. > > Sounds promising. :-) However, your array_comparison_performance > handles the last 1-7 bytes byte-by-byte. My array_compare branch > reserves extra 7 bytes at the end of the array so that one can safely > read up to 7 bytes more than one actually needs. This way no bounds > checks are needed (even with Unsafe). This might affect the comparision > between Arrays.mismatch and VarHandle if the results were close before. > > > I do like Unsafe as an option for jdk 8 users on x86 or arm64. > > Unsafe seems very slightly faster than VarHandle. If Java 8 uses Unsafe, > should newer versions do too? It could be counter-productive if Java 8 > was faster, even if the difference was tiny. > > Do you have use cases that are (for now) stuck on Java 8 or is your > wish a more generic one? > > -- > Lasse Collin >
