BLAS and Vector API

[Samuel Audet]

Wow, that's a lot of documents, thanks! I wasn't aware of half of these 
new links. I'm a bit disappointed though that I'm still not finding much 
of anything concerning performance, but that's nothing new. I understand 
there are other priorities. I'm still not convinced that all this work 
is going to provide something sufficiently more usable than JNI and 
sun.misc.Unsafe for people to "migrate". Yes, I know, we'll see when 
it's done.

BTW, one new thought I had recently. One measure of success could be 
seeing Google going through all the legal and technical hoops to have 
this ported to Android. If they stick with JNI, then I suppose that 
means most developers may very well stick with JNI, at least until 
something else sufficiently "better" comes around, which might end up 
not being related to Panama at all.

Samuel

On 1/5/21 8:14 PM, Maurizio Cimadamore wrote:
> 
> On 05/01/2021 00:56, Samuel Audet wrote:
>> Hi, Maurizio,
>>
>> On 1/5/21 1:22 AM, Maurizio Cimadamore wrote:
>>>
>>> On 04/01/2021 14:52, Samuel Audet wrote:
>>>> Hi, Ludovic,
>>>>
>>>> On 1/4/21 10:48 PM, Ludovic Henry wrote:
>>>>> I’ll also explore using the Foreign Linker API to wrap the OpenBLAS 
>>>>> library without going through JNI. I’m curious whether it’s going 
>>>>> to lead to performance improvements.
>>>>
>>>> No, not yet, it won't, since that still uses JNI:
>>>> https://github.com/microsoft/onnxruntime/pull/4329#issuecomment-673848183
>>>
>>>
>>>
>>> Where did you get this information from? The comment you quote shows 
>>> my reply and then you somehow (erroneously) inferring that the linker 
>>> API is based on JNI.
>>>
>>> The Foreign Linker API support has very little to do with JNI 
>>> support. Of course, since some of the stuff the VM has to do to go 
>>> from Java to native are the same, performances might not be too 
>>> different (unless state transitions are removed, which is possible 
>>> with the linker API).
>>
>> OpenJDK hasn't been providing a lot of updates about the status of the 
>> various Panama APIs for a year or so now, so I can only assume that 
>> things had not changed. Also, since you're not replying to messages 
>> containing information about what you said of the state of things in 
>> the past (that the foreign API was using JNI, I can dig up the 
>> specific message if you want), I simply assumed that things had not 
>> changed! Sorry about that
>>
>> I'll say it again: Keeping all this information "internal" isn't 
>> helping the community. I understand that you probably don't have any 
>> say in this, that it's all about policies at Oracle, so please don't 
>> take it personally. As usual, thanks for updating us with the 
>> information you can provide.
> 
> I think there has been plenty of information available during 2020:
> 
> https://inside.java/tag/panama
> 
> There are public talks linked in the page above - unfortunately, they 
> only cover the memory access part - since that's where we were back in 
> February (when we still could do conferences - or attend them :-) ).
> 
> Jorn and I recorded a podcast (also linked above) last December, also 
> covering both APIs (it's in two parts).
> 
> Several writeups on the current status of the APIs (both memory access 
> AND linker) have been live on github for the past few months. Jorn also 
> wrote a more technical writeup on the status of the VM intrinsics for 
> downcall support, which helped the review process quite a bit.
> 
> Speaking of reviews, both PRs for memory access and linker API are 
> public and contain tons of info as well:
> 
> https://github.com/openjdk/jdk/pull/548
> 
> https://git.openjdk.java.net/jdk/pull/634
> 
> If you follow the links, you will find comprehensive JEP documents, CSRs 
> - all info has been available to see (as for any other changes to the 
> Java platform).
> 
> 
> Should be enough at least to understand where we are at and where we're 
> going?
> 
> Cheers
> Maurizio
> 
> 
> 
>>
>> Samuel