Java shared memory

[Paul Sandoz]

Hi Radek,

> On 31 May 2016, at 00:57, Radek <rsmogura at gmail.com> wrote:
> 
> Dear Andrew,
> 
> I’ve just modified test case to convert bytes to long in code. The results are comparable.
> 
> Attached please find out files. Those are named as follow:
> * memorymap - from MemoryMapMinMax, file map from FileMapMinMax
> * memorymap2, filemap2 form *Bytes version respectively
> 
> I’m attaching text files with results, and test classes (those are my test classes, so not nicely formatted).
> 
> I could do something wrong with C2, but I think results are expected as NIO in back copies mapped array to Java array, does it?
> 

Like Andrew my expectation was that a long view over a mapped byte buffer should not be significantly different.

(Note: it’s hard to evaluate these kind of things without using JMH and also looking at the generated code).

Here is your main loop for LongBuffer:

        while (lbuff.hasRemaining()) {
            lbuff.get(ll);
            for (long l : ll) {
                if (l < min) min = l;
                if (l > max) max = l;
                lastNumber = l;
            }
        }

You are bulk copying into an array, that alone could explain an ~2x performance difference.

Instead, use the indexed accessors LongBuffer.get(int ) e.g.something like:

for (int i = 0; i < lbuffer.limit(); i++) {
  l = lbuff.get(i);
  if (l < min) min = l;
  if (l > max) max = l;
  lastNumber = l;  ...
}

If you take a closer look at the buffer source you will notice long views over byte buffers are optimized in certain cases to direct calls to Unsafe.get/setLong.

While lbuff.get(i) is not ll[i], it’s not far off :-)


Relatedly, see the recent work by Mr. (David) Simms on this list, so that int[] implements Arrayish<int>. I dunno if this can apply to classes, such as making LongBuffer implement Arrayish<long>, and (thinking out loud) javac can support the array syntax for all arrayish things.

Paul.


> Best regards,
> Radek
> 
> <filemap2_100000_jdkmod_oopcomp1_feature0.txt><filemap2_100000_jdkmod_oopcomp1_feature0.txt><memorymap_134217728_jdk9mod_oopcomp1_feature1.txt><memorymap2_134217728_jdk9mod_oopcomp1_feature1.txt>
> <FileMapMinMax.java><FileMapMinMaxBytes.java><MemoryMapMinMax.java><MemoryMapMinMaxBytes.java>
>> On 30 May 2016, at 22:10, Andrew Haley <aph at redhat.com> wrote:
>> 
>> On 30/05/16 19:48, Radek wrote:
>> 
>>> I’m able to map part of files as primitive java arrays. First
>>> performance results are very optimistic (40% boost in searching
>>> min-max long in 1GB file) with mapped long[] as a replacement to
>>> LongBuffer.
>> 
>> It shouldn't be significantly different in performance.  Perhaps you
>> can share your benchmark with us.  Maybe we're missing vectorization
>> opportunities.
>> 
>> Andrew.
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160531/b9cbaf34/signature.asc>