On Feb 27, 2014, at 4:12 PM, Andrew Haley <a...@redhat.com> wrote: > On 02/27/2014 03:05 PM, Paul Sandoz wrote: >> >> On Feb 27, 2014, at 3:52 PM, Andrew Haley <a...@redhat.com> wrote: >> >>> Hi, >>> >>> On 02/26/2014 03:42 PM, Paul Sandoz wrote: >>> >>>> A common reason why Unsafe is used is to more efficiently compare two >>>> unsigned byte arrays, viewing those byte arrays as long arrays. >>> >>> Why not simply provide ByteBuffer.forArray(byte[]) ? Then we'd have all >>> the ByteBuffer intrinsics for put() and get() operations. >> >> Good point, even if it does require the creation of two ByteBuffer instances. >> >> An implementation of Arrays.compare could do that if things were suitably >> intrinsified, which i am not sure is the case as of today. >> >> I will do some measurements and report back. > > Unless something has been done in HotSpot pretty recently, the > ByteBuffer intrinsics are not as performat as they might be, so the > results might be a little underwhelming. >
Yes. For this benchmark: http://cr.openjdk.java.net/~psandoz/unsafe/ByteArrayCompareTest.java Here are results for comparing two byte arrays of size N containing the same content, on my mac book: http://cr.openjdk.java.net/~psandoz/unsafe/byte-array-compare-results.txt The unsafe test is about ~3/4 x faster than the safe test. And the buffer test is slower than the safe test. I also included a variant of the unsafe test that uses Long.reverseBytes; the results are similar to the unsafe test. I believe reverseBytes is intrinsified as is numberOfTrailingZeros (i tried to disable it with -XX:DisableIntrinsic=_reverseBytes_l but it did not make any great different to the results, which makes me think i configured the option incorrectly). Paul.
