Unsafe: efficiently comparing two byte arrays

Andrew Haley aph at redhat.com
Thu Mar 13 17:17:27 UTC 2014

On 03/13/2014 05:02 PM, Paul Sandoz wrote:
> 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 see.  Yes, what you said is clear, now I read it again.  :-)

> 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?

That's hard to say for sure.  It might well be so, but I suspect
you'll hit memor bandwidth limits in both cases.

> 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.

OK, so I think I understand now: you can do what you need without
having to drag in HotSpot engineers.  But Unsafe only works really
efficiently when it is intrinsified.

> 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.

Ok, fair point.


More information about the core-libs-dev mailing list