jextract looses type safety in generated bindings

[Maurizio Cimadamore]

On 07/04/2021 15:35, Michael Böckling wrote:
> This is great, thanks! I had seen that benchmark before and wondered 
> what the numbers would be for the current version. Maybe you can 
> publish those numbers somewhere? "Scientific" or not, the general 
> trend is surely correct. I'm not yet sure how important the per-call 
> overhead will be for my use case, good to know that Panama is a 
> high-performance candidate.

Yeah - it would be nice to get the benchmark revisited - I'll see if I 
can contact the author.

Cheers
Maurizio

>
> Am Mi., 7. Apr. 2021 um 15:43 Uhr schrieb Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com <mailto:maurizio.cimadamore at oracle.com>>:
>
>
>     On 07/04/2021 11:57, Maurizio Cimadamore wrote:
>     > If the latter, we had an API similar to that in an earlier
>     iteration
>     > of the Panama project (another Pointer-like API); while this API
>     was
>     > enough, from an expressiveness perspective, to support jextract use
>     > cases, it also added noticeable overhead to basic operation like
>     > pointer dereference.
>
>     To give a better ideas of the numbers involved - there is a nice
>     native
>     interop shootout here:
>
>     https://github.com/zakgof/java-native-benchmark
>     <https://urldefense.com/v3/__https://github.com/zakgof/java-native-benchmark__;!!GqivPVa7Brio!L4bB9JVXV-8XfR4ShSaak5U8SmRV4uwq86vx_uRRZe8vFKw4ygLvYyEtxMqsDW_5uaafgXY$>
>
>     This was ran against the old Panama API, the one featuring the
>     high-level Pointer API. As you can see Panama doesn't come out too
>     well
>     in that benchmark.
>
>     For fun, I've ported the benchmark using the API we have released in
>     Java 16, and here are the results I have:
>
>     ```
>     Benchmark                                   Mode  Cnt Score    
>     Error  Units
>     JmhCallOnly.bridj                           avgt   50 279.563 ▒
>     4.312  ns/op
>     JmhCallOnly.jna                             avgt   50 826.049 ▒
>     11.840  ns/op
>     JmhCallOnly.jna_direct                      avgt   50 934.675 ▒
>     13.662  ns/op
>     JmhCallOnly.jni_javacpp                     avgt   50 36.899 ▒
>     0.618  ns/op
>     JmhCallOnly.jnr                             avgt   50 233.757 ▒
>     3.090  ns/op
>     JmhCallOnly.panama                          avgt   50 30.332 ▒
>     0.386  ns/op
>     JmhGetSystemTimeSeconds.bridj               avgt   50 1306.806 ▒
>     131.925  ns/op
>     JmhGetSystemTimeSeconds.java_calendar       avgt   50 136.437 ▒
>     3.949  ns/op
>     JmhGetSystemTimeSeconds.java_date           avgt   50 50.450 ▒
>     0.750  ns/op
>     JmhGetSystemTimeSeconds.java_localdatetime  avgt   50 58.232 ▒
>     1.456  ns/op
>     JmhGetSystemTimeSeconds.jna                 avgt   50 3194.622 ▒
>     216.633  ns/op
>     JmhGetSystemTimeSeconds.jnaDirect           avgt   50 3227.971 ▒
>     193.953  ns/op
>     JmhGetSystemTimeSeconds.jni_javacpp         avgt   50 418.683 ▒
>     5.789  ns/op
>     JmhGetSystemTimeSeconds.jnr                 avgt   50 327.486 ▒
>     7.548  ns/op
>     JmhGetSystemTimeSeconds.panama              avgt   50 390.615 ▒
>     3.987  ns/op
>     ```
>
>     (all this has been ran unscientifically, using a VirtualBox
>     instance :-) )
>
>
>     As you can see, the API we have in 16 are pretty competitive with
>     JNI -
>     only JNR does better, but I believe that's due to differences in how
>     memory is allocated - e.g. the memory segment API does a malloc and a
>     free, and it also zeroes memory (as well as keeping track of how much
>     memory has been allocated in the JDK as a whole, which is a need for
>     us). I'm pretty sure that (a) JNR doesn't bother with any of this
>     (rightfully so!) and (b) if we started playing with custom segment
>     allocators (which the latest API allows you to do) we can obtain
>     numbers
>     which surpass everything seen here (as we can amortize the
>     allocation cost).
>
>     When it comes to overhead for a single native call (e.g. ignoring
>     memory
>     allocation overhead), you can see that the Linker API in 16 comes out
>     the best of the bunch.
>
>     So, every interop solution in this space picks a different compromise
>     when it comes to expressiveness vs. performance. You can see how our
>     APIs have benefited by going lower level - we started off being the
>     slowest and ended up there with the best (there is some 10x gain in
>     there). Of course users are free to pick the solution they prefer,
>     depending on the particular use cases they are facing.
>
>     Maurizio
>
>