[External] : Re: MemorySegment.ofAddress(...).reinterpret(...)

[Maurizio Cimadamore]

Hi Brian,
I have been playing some more with the benchmark you provided here:

https://gist.github.com/broneill/3a39051635e3cb758d0cca5a963c685e

The following patch seems to help quite significantly:

https://cr.openjdk.org/~mcimadamore/panama/segment_normalize_offsets.patch

Here are the benchmark results:

(before)

|Benchmark Mode Cnt Score Error Units BinarySearch.binarySearch_panama 
avgt 30 61.404 ? 1.315 ns/op BinarySearch.binarySearch_unsafe avgt 30 
28.099 ? 0.330 ns/op |

(after)

|Benchmark Mode Cnt Score Error Units BinarySearch.binarySearch_panama 
avgt 30 38.103 ? 0.471 ns/op BinarySearch.binarySearch_unsafe avgt 30 
27.556 ? 0.208 ns/op |

We believe there must be some C2 issue lurking in there - basically 
we’re forcing all offsets to be positive using this:

|@ForceInline private static long normalize(long offset) { if (offset < 
0) { throw new IndexOutOfBoundsException("Offset is < 0"); } return 
offset & Long.MAX_VALUE; } |

Now, surprisingly, if the “& Long.MAX_VALUE” is dropped, performance 
dips again. I believe we lose track of the positivity here and the above 
patch provides some kind of workaround.

I’d be interested to know if this patch helps the situation with your 
bigger benchmark, or if things stay the same (in which case, we would 
have to conclude that this benchmark, while interesting, is perhaps not 
reflective of the issues in your bigger codebase).

Thanks
Maurizio

On 06/07/2023 23:19, Brian S O’Neill wrote:

> When I use the "ALL" MemorySegment instead of allocating 
> MemorySegments on the fly for copies, the performance regression drops 
> to ~2%.

​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20230721/420e1c21/attachment.htm>