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.
Paul.
More information about the core-libs-dev
mailing list