On 2024-03-12 Brett Okken wrote: > I am still working on digesting your branch.
I still need to check a few of your edits if some of them should be included. :-) > 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 pushed basic docs for getMatchLen. Once crc64_varhandle2 is merged then array_compare should use ArrayUtil too. It doesn't make a difference in speed. > 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 can wait for the summary, thanks. > I am not sure when I will get opportunity to test out arm64. If someone has, for example, a Raspberry Pi, the compression of zeros test is simple enough to do and at least on x86-64 has clear enough difference. It's an over-simplified test but it's a data point still. > 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. Thanks. I was already tilted towards not using Unsafe and now I'm even more. The speed benefit of Unsafe over VarHandle should be tiny enough. It feels better that memory safety isn't ignored on any JDK version. If a bug was found, it's nicer to not wonder if Unsafe had a role in it. This is better for security too. In my previous email I wondered if using Unsafe only with Java 8 would make upgrading to newer JDK look bad if newer JDK used VarHandle instead of Unsafe. Perhaps that worry was overblown. But the other reasons and keeping the code simpler make me want to avoid Unsafe. (C code via JNI wouldn't be memory safe but then the speed benefits should be much more significant too.) -- Lasse Collin
