SPARC <was> Re: RFR 8151163 All Buffer implementations should leverage Unsafe unaligned accessors
Paul Sandoz
paul.sandoz at oracle.com
Wed Mar 30 11:05:42 UTC 2016
> On 30 Mar 2016, at 12:10, Andrew Haley <aph at redhat.com> wrote:
>
> On 03/30/2016 10:36 AM, Paul Sandoz wrote:
>
>> Unsafe.getLongUnaligned needs to perform three alignment checks
>> before accessing bytes and then optionally perform a byte
>> swap. Bits.getLong always access bytes and composing using the
>> defined endianness and requires no additional byte swap.
>>
>> Since SPARC is Big Endian and buffers are by default Big Endian i
>> can rule any byte swapping, but it potentially could increase the
>> regression if Little Endian is chosen [2].
>>
>> When access is performed in loops this can cost, as the alignment
>> checks are not hoisted out. Theoretically could for regular 2, 4, 8
>> strides through the buffer contents. For such cases alignment of the
>> base address can be checked. Not sure how complicated that would be
>> to support.
>
> Going back to the "Unsafe.{get,put}-X-Unaligned performance" and
> "Unsafe.{get,put}-X-Unaligned; Efficient array comparison intrinsics"
> discussion a year ago, the rationale behind the way things are was to
> enable auto-vectorization. We certainly can do things with more
> complex checks at the Java level, but IMVHO vectorization is the right
> way to fix it.
>
I would be reluctant to add more complex checks to the Java implementation, it’s likely to push around the regression on SPARC.
Unsafe.get*Unaligned is a "poor man’s” form of vectorization :-) But you are right that a higher-level vectorization of loops is a better longer term overall strategy, however that will still be tricky for architectures that can only vectorize with access on aligned boundaries.
I am trying to think of opportunistic shorter term fixes that might work on current SPARC architectures.
Paul.
More information about the core-libs-dev
mailing list