Array equality, comparison and mismatch (original) (raw)

Paul Sandoz paul.sandoz at oracle.com
Thu Oct 15 10:52:31 UTC 2015

On 13 Oct 2015, at 12:03, Andrew Haley <aph at redhat.com> wrote:

On 13/10/15 10:22, Paul Sandoz wrote: Analysis so far indicate big gains are to be had on larger arrays with better or no impact on small arrays if i do the following instead:

if (Double.doubleToRawLongBits(a[i]) != Double.doubleToRawLongBits(b[i])) { int c = Double.compare(a[i], b[i]); if (c != 0) return c; } I was about to make a similar comment. My experiment was with if (Double.doubleToRawLongBits(a[i]) != Double.doubleToRawLongBits(b[i]) && (Double.doubleToLongBits(a[i]) != Double.doubleToLongBits(b[i]))) return Double.compare(a[i], b[i]); } which is about twice as fast as the original version, as is yours. But yours is more elegant. :-)

Thanks :-) updated:

http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexico-compare/webrev/

It's a shame that HotSpot doesn't see through the load of a double and then the conversion through doubleToRawLongBits: it could just load directly into the integer registers.

The following webrev explicitly does what you mention above and is faster for mismatching double arrays (with no differing NaN values):

http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8136924-arrays-mismatch-vectorized-unsafe/webrev/

I would be very interested in your opinion on being able to make intrinsic on ARM the method ArraysSupport.vectorizedMismatch [1].

Paul.

[1] http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8136924-arrays-mismatch-vectorized-unsafe/webrev/src/java.base/share/classes/java/util/ArraysSupport.java.html

More information about the core-libs-dev mailing list