Unsafe: efficiently comparing two byte arrays (original) (raw)

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.

Andrew.



More information about the core-libs-dev mailing list