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/hotspot-compiler-dev/attachments/20160531/e09a413f/JSM_Mapping_results.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MemoryMapMinMax.java
Type: application/octet-stream
Size: 2101 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160531/e09a413f/MemoryMapMinMax.java>
-------------- 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.
>>
>