On Mar 13, 2014, at 5:26 PM, Andrew Haley <a...@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.
