Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dramatic speed difference of Native Calls via JNA between various JDK, why? #254

Closed
manticore-projects opened this issue Nov 15, 2023 · 4 comments

Comments

@manticore-projects
Copy link

Greetings!

First of all, thank you for providing Jetbrains JDK. I managed to wrap different optimized native PNG encoders into a Java Library and ran it successfully on Jetbrains JDK 11 and 21. Please see https://github.com/manticore-projects/fpng-java for details.

However, benchmarks revealed surprising results when using GraalVM vs. OpenJDK or JetBrains JDK:

  • the pure Java Encoders run with comparable speed (which is expected, the JDK should NOT differ that much)
  • however, the NATIVE Encoders were MUCH faster (like 50%) on GraalVM 11 and 21 compared to OpenJDK and JetBrains JDK 11 and 21

Details of the Benchmark Results are here: https://github.com/manticore-projects/fpng-java#benchmarks

The code and the machine is the same. Everything was cleaned and freshly compiled. I repeated the tests many time and I do believe I know how to benchmark properly.

I also tried on a self-compiled, optimized "-O3 -march=native" JetBrains JDK version with all possible optimizations. It did not improve the results and only confirmed the "slow" observations on JetBrains JDK or OpenJDK.
So it does not seem to be about compile optimization of the JDK alone.

Please can you provide any idea or hint, why there is this massive performance difference, but only for the native encoders? I am completely lost and don't trust those results or my skills.

Further, please don't feel offended when I will ask the same question at GraalVM and JNA forums.

Thanks for your advise in advance and cheers!

@mkartashev
Copy link
Collaborator

Hello! There seem to be no reason why you can't use GraalVM with JetBrains Runtime (JBR) if that gives you a performance boost. The greatest value of the JBR lies in Java Runtime Environment, mostly in the client part of that. Apart from DCEVM, we have a very small amount of changes in the JVM itself and certainly none in the area of performance.

@manticore-projects
Copy link
Author

Thank you for prompt response although I still wonder: Does it appear reasonable/expected that the Native Libs are executed so much faster? Did you make similar observations when calling Native Libs?

I do not trust those results but also have no explanation for it.
Is there a better place to discuss or ask/investigate please?

@mkartashev
Copy link
Collaborator

Does it appear reasonable/expected that the Native Libs are executed so much faster? Did you make similar observations when calling Native Libs?

I'm not aware of any similar experiment.

Is there a better place to discuss or ask/investigate please?

Sorry, don't have an answer to this one.

@manticore-projects
Copy link
Author

Thank you Maxim. I guess I will have to run more tests and fiddle around with GC and or memory settings, worst case profiling.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants