Unsafe: efficiently comparing two byte arrays

Paul Sandoz paul.sandoz at oracle.com
Thu Mar 13 17:02:11 UTC 2014

On Mar 13, 2014, at 5:26 PM, Andrew Haley <aph at redhat.com> wrote:
>>>> A quick solution is to leverage Unsafe within a
>>>> ByteBuffer.compareUnsigned method. In fact i believe Unsafe could be
>>>> used (as Aleksey says in [1]) for put/get as well, which i presume
>>>> is likely to be much easier/quicker to implement. Might be a good
>>>> first step until a more superior intrinsics solution is implemented?
>>> I still don't get it, sorry.  What can Unsafe do that ByteBuffer
>>> intrinsics can't do?
>> We can arguably implement it faster [2]
> I doubt that very much.  In fact, I would say that it is almost
> certainly not true.  HotSpot usually knows, for example, when both
> offsets are zero and can generate better code for machines with strict
> alignment.
> And also, Unsafe has the same speed problems with unaligned data
> that an intrinsic would have.

I meant i can *implement* a comparison solution using Unsafe faster than i can implement a more general solution using intrinsics. 

I presume intrinsics might be of great advantage if SIMD instructions can be leveraged? if not would it be reasonable to assume that for common 0 offset case the two solutions might be similar in terms of performance?

>> and i presume it will be simpler too.
> And that.
> But the key point is this: we want intrinsics for ByteBuffers anyway.

Yeah, but i think that could take longer and there is also the Arrays 2.0 work to consider, the scope is considerably larger than providing an efficient comparison method for byte[] arrays. 

It is possible to tackle this simple use-case with an API tweak (ByteBuffer.compareUnsigned) and revisit the implementation if/when instincts for arrays get into 9. That is a small but useful step in the right direction.


More information about the core-libs-dev mailing list