Unsafe: efficiently comparing two byte arrays
paul.sandoz at oracle.com
Thu Feb 27 17:23:28 UTC 2014
On Feb 27, 2014, at 4:12 PM, Andrew Haley <aph at redhat.com> wrote:
> On 02/27/2014 03:05 PM, Paul Sandoz wrote:
>> On Feb 27, 2014, at 3:52 PM, Andrew Haley <aph at redhat.com> wrote:
>>> 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.
For this benchmark:
Here are results for comparing two byte arrays of size N containing the same content, on my mac book:
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).
More information about the core-libs-dev