Unsafe: efficiently comparing two byte arrays
martinrb at google.com
Fri Feb 28 22:29:03 UTC 2014
Are word-size reads in ByteBuffer actually intrinsified? I could find no
evidence for that. Perhaps this is an important missing optimization for
hotspot to make?
I see DirectByteBuffer, but not garden-variety ByteBuffer, using Unsafe.
Probably should be investigated using disassembly of jitted code, which I
have never done.
I've been on both sides of the Unsafe-using fence. On the one hand I
helped implement LexicographicalComparator, and on the other dissuade
others from adding even more usages of Unsafe.
On Thu, Feb 27, 2014 at 9:23 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> On Feb 27, 2014, at 4:12 PM, Andrew Haley <aph at redhat.com> wrote:
> > On 02/27/2014 03:05 PM, Paul Sandoz wrote:
> >> On Feb 27, 2014, at 3:52 PM, Andrew Haley <aph at redhat.com> wrote:
> >>> Hi,
> >>> On 02/26/2014 03:42 PM, Paul Sandoz wrote:
> >>>> A common reason why Unsafe is used is to more efficiently compare two
> unsigned byte arrays, viewing those byte arrays as long arrays.
> >>> Why not simply provide ByteBuffer.forArray(byte) ? Then we'd have
> all the ByteBuffer intrinsics for put() and get() operations.
> >> Good point, even if it does require the creation of two ByteBuffer
> >> An implementation of Arrays.compare could do that if things were
> suitably intrinsified, which i am not sure is the case as of today.
> >> I will do some measurements and report back.
> > Unless something has been done in HotSpot pretty recently, the
> > ByteBuffer intrinsics are not as performat as they might be, so the
> > results might be a little underwhelming.
> For this benchmark:
> Here are results for comparing two byte arrays of size N containing the
> same content, on my mac book:
> The unsafe test is about ~3/4 x faster than the safe test. And the buffer
> test is slower than the safe test.
> I also included a variant of the unsafe test that uses Long.reverseBytes;
> the results are similar to the unsafe test. I believe reverseBytes is
> intrinsified as is numberOfTrailingZeros (i tried to disable it with
> -XX:DisableIntrinsic=_reverseBytes_l but it did not make any great
> different to the results, which makes me think i configured the option
More information about the core-libs-dev