Performance of memory var handles in hot loops

[Maurizio Cimadamore]

On 08/04/2020 11:52, Antoine Chambille wrote:
> Thank you for the information.
>
> Looking forward to when all the pieces will come together. It's a bit 
> magic at the moment, in a good way, and in a puzzling way ;)
>
> Does this microbenchmark qualify as a 'long loop' ? Even though the i 
> counter of the loop is an int?

Well, the loop itself is an int loop. But all the operations done 
internally (offset addition and such) are long operation in the memory 
access API. So currently we have forks in the code and special flags to 
indicate whether a segment is "small" or not, in which case we know we 
can go back to use int additions/multiplications. These heroics work to 
some degree, but having things working correctly at the C2 level would 
be preferrable, as I suspect that we are also adding a lot of noise.

Maurizio

>
>
> Yes the vector API works well on native memory exposed as byte 
> buffers, performance is better than scalar but not yet on par with the 
> vector API on arrays. I have actually tried it recently on the same 
> kind of benchmark. 
> http://mail.openjdk.java.net/pipermail/panama-dev/2020-March/007786.html. 
> That's when John Rose mentioned that the vector API would support 
> memory segments, and hinted that it would be the preferred way to use 
> the vector API on native memory.
>
> Cheers,
> -Antoine
>
>
>
>
>
>
> On Wed, Apr 8, 2020 at 12:21 PM Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com 
> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>
>
>     On 08/04/2020 08:58, Antoine Chambille wrote:
>     > I'm not too worried about that because the panama vector API is
>     > coming. By the way is there already a prototype of the Vector
>     API that
>     > works on memory segments?
>
>     No, I think ATM the vector API doesn't have a way to load a vector
>     from
>     a memory segment. That said, IIRC it has ways to load it from a
>     ByteBuffer and you can turn the segment into a BB (provided it
>     fits into
>     a 32-bit size).
>
>     I did some experiments in the past about bridging the two APIs, the
>     results I got were a bit hit and miss but it was a long time ago -
>     maybe
>     it's time to do another attempt.
>
>     Maurizio
>
>