<div dir="ltr"><div>I added two test results, namely the case of disabling C2 (using C1) and the case of disabling JIT compiler (only interpreter):</div><div><br></div>    <a href="https://github.com/Glavo/java-ffi-benchmark/tree/main/data/1" target="_blank">https://github.com/Glavo/java-ffi-benchmark/tree/main/data/1</a><br><div><br></div><div>The purpose of these benchmarks is to understand the performance of Panama during the warm-up phase or on the Client VM.<br></div><div><br></div><div>When using C1, Panama is usually much slower than JNI, but not inferior to JNR, and still much faster than JNA. <br></div><div>One exception is the upcall stub, in which case Panama is still several times faster than other solutions.</div><div><br></div><div>When using an interpreter, Panama is slower, even slower than JNA Direct Mapping, but still a bit faster than regular use of JNA.<br></div><div><br></div><div>Well, this is not an unexpected result, after all, MethodHandle needs to be fully optimized by the C2 compiler to have good performance.<br></div><div>While I wish its implementation on the interpreter was faster, even the slower JNA is widely used, so the performance of Panama's warm-up phase is still acceptable.<br></div><div><br></div><div>However, there is still a noteworthy issue: The strlen implementation I optimized earlier is much slower on both C1 and interpreter than the old implementation.<br></div><div>It seems that C1 has not optimized the Vector API. I think in order to preheat the speed, the Vector API should not be used here, but should be implemented as C1/C2 Intrinsic.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Mar 25, 2023 at 3:07 AM Glavo <<a href="mailto:zjx001202@gmail.com">zjx001202@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I have run a series of benchmarks of Panama, JNI, JNA, and JNR based on the latest JDK. Here is its GitHub repository:<br><div><br></div><div>    <a href="https://github.com/Glavo/java-ffi-benchmark" target="_blank">https://github.com/Glavo/java-ffi-benchmark</a></div><div><br></div><div>Here I tested the performance of no-ops, accessing structs, string conversions, and callbacks, respectively. I also tried the new isTrivial linker option.</div><div>I summarized the results in README and charted them.<br></div><div><br></div><div>In this email, in addition to sharing the above results, I would also like to talk about several issues I have encountered<br></div><div><br></div><div>1. MemorySegment.getUtf8String is unexpectedly slow</div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>Panama is much faster than JNA in most cases, but the operation of converting C strings to Java strings is an exception.</div><div>I checked the source code of JNA and Panama, and the suspicious difference is that JNA uses strlen from the C standard library, while Panama uses Java loops. </div><div>Perhaps this method can be optimized.</div></blockquote><div><br></div><div>2. StructLayout must manually specify all padding</div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>Can we provide a convenient method for automatically padding between fields based on alignment?</div><div>The current structLayout method is annoying for situations where you need to manually simulate the layout of a C struct.</div></blockquote><div><br></div><div>Glavo</div></div>
</blockquote></div>