Java shared memory

Radek rsmogura at gmail.com
Tue May 31 10:44:16 UTC 2016


Dear Paul and Adrew,

Indeed I’ve messed up with a coping long. I don’t know why I have done it, as my first approach actually involved buff.getLong(). I’ve took, as well, closer look at my tests and right now I use JDK9 build 120, as a reference points.

There is a performance gain (build 120 vs custom slow debug) but right now it’s 12%, not so huge. Maybe after code polishing and additional optimisation I could get 15-20%. 

I don’t know if in such a case my work could be interesting.

Best regards,
Radek 
PS Attached please find latest results, the MappedByteBuffer case uses for (int i=0; i < mbuff.limit(); i+=8) loop.


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: JSM_Mapping_results.txt
URL: <http://mail.openjdk.java.net/pipermail/valhalla-dev/attachments/20160531/e09a413f/JSM_Mapping_results.txt>
-------------- next part --------------


> On 31 May 2016, at 10:27, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> 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.
>> 
> 



More information about the valhalla-dev mailing list