> On 31 Mar 2016, at 09:40, Peter Levart wrote:
>
>
>
> On 03/31/2016 08:33 AM, John Rose wrote:
>> On Mar 30, 2016, at 2:36 AM, Paul Sandoz wrote:
>>> When access is performed in loops this can cost, as the alignment checks
>>> are not
Hi John,
Thanks for the thoughts and advice.
At this point i plan to proceed with the current patch (i will add tests for
buffer views), and then follow up more more analysis and recommendations for
SPARC. The situation is a little murky after some further performance analysis,
non-optimal
On 03/31/2016 08:33 AM, John Rose wrote:
On Mar 30, 2016, at 2:36 AM, Paul Sandoz wrote:
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
On Mar 30, 2016, at 2:36 AM, Paul Sandoz wrote:
>
> 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
> On 30 Mar 2016, at 12:10, Andrew Haley 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
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.
>
>
Hi,
Some performance analysis on SPARC revealed two anomalies:
1) the first was an embarrassing bug in the buffer views calculating the
incorrect offset, which has been rectified in the latest webrev: