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 --------------
Test adjusted to use mbuff.getLong(i), and long[] array mapping
JDK 9 Build 120 JDK 9 Cutom Build - Shared Memory (Memory Map) Slowdebug
Nano time Nano time Memory
0 -9223371862571790000 9223371789026350000 c5fad8b6a1df6ee7 244291849 13518400 0 -9223371981257440000 9223372014692500000 e76edfa1b6d8fac5 184950417 13518400
1 -9223371862571790000 9223371789026350000 c5fad8b6a1df6ee7 195346549 13518400 1 -9223371981257440000 9223372014692500000 e76edfa1b6d8fac5 106616532 13518400
2 -9223371862571790000 9223371789026350000 c5fad8b6a1df6ee7 121570929 13518400 2 -9223371981257440000 9223372014692500000 e76edfa1b6d8fac5 127497407 13518400
3 -9223371862571790000 9223371789026350000 c5fad8b6a1df6ee7 117335059 13518400 3 -9223371981257440000 9223372014692500000 e76edfa1b6d8fac5 104488812 13518400
4 -9223371862571790000 9223371789026350000 c5fad8b6a1df6ee7 117780019 13518400 4 -9223371981257440000 9223372014692500000 e76edfa1b6d8fac5 105211295 13518400
5 -9223371862571790000 9223371789026350000 c5fad8b6a1df6ee7 120533520 13518400 5 -9223371981257440000 9223372014692500000 e76edfa1b6d8fac5 105539383 13518400
6 -9223371862571790000 9223371789026350000 c5fad8b6a1df6ee7 114415986 13518400 6 -9223371981257440000 9223372014692500000 e76edfa1b6d8fac5 105097731 13518400
7 -9223371862571790000 9223371789026350000 c5fad8b6a1df6ee7 124678261 13518400 7 -9223371981257440000 9223372014692500000 e76edfa1b6d8fac5 103681691 13518400
8 -9223371862571790000 9223371789026350000 c5fad8b6a1df6ee7 124404309 13518400 8 -9223371981257440000 9223372014692500000 e76edfa1b6d8fac5 107119637 13518400
9 -9223371862571790000 9223371789026350000 c5fad8b6a1df6ee7 119446006 13518400 9 -9223371981257440000 9223372014692500000 e76edfa1b6d8fac5 103115650 13518400
10 -9223371862571790000 9223371789026350000 c5fad8b6a1df6ee7 116717629 13518400 10 -9223371981257440000 9223372014692500000 e76edfa1b6d8fac5 106512042 13518400
11 -9223371862571790000 9223371789026350000 c5fad8b6a1df6ee7 117376732 13518400 11 -9223371981257440000 9223372014692500000 e76edfa1b6d8fac5 105973469 13518400
12 -9223371862571790000 9223371789026350000 c5fad8b6a1df6ee7 122044672 13518400 12 -9223371981257440000 9223372014692500000 e76edfa1b6d8fac5 108403908 13518400
13 -9223371862571790000 9223371789026350000 c5fad8b6a1df6ee7 130149493 13518400 13 -9223371981257440000 9223372014692500000 e76edfa1b6d8fac5 112014577 13518400
14 -9223371862571790000 9223371789026350000 c5fad8b6a1df6ee7 124465626 13518400 14 -9223371981257440000 9223372014692500000 e76edfa1b6d8fac5 113096644 13518400
15 -9223371862571790000 9223371789026350000 c5fad8b6a1df6ee7 125535077 13518400 15 -9223371981257440000 9223372014692500000 e76edfa1b6d8fac5 109080338 13518400
16 -9223371862571790000 9223371789026350000 c5fad8b6a1df6ee7 136130003 13518400 16 -9223371981257440000 9223372014692500000 e76edfa1b6d8fac5 112686846 13518400
17 -9223371862571790000 9223371789026350000 c5fad8b6a1df6ee7 119225157 13518400 17 -9223371981257440000 9223372014692500000 e76edfa1b6d8fac5 111096844 13518400
18 -9223371862571790000 9223371789026350000 c5fad8b6a1df6ee7 112781943 13518400 18 -9223371981257440000 9223372014692500000 e76edfa1b6d8fac5 102728661 13518400
19 -9223371862571790000 9223371789026350000 c5fad8b6a1df6ee7 121864524 13518400 19 -9223371981257440000 9223372014692500000 e76edfa1b6d8fac5 101737681 13518400
Differences
Avarage nano
121463766 14 546 989 106916777
Avarage %
12%
-------------- 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