Clojurians Log v2
graalvm
What is the status of graalvm from what I understand they are still not as fast for long term compute compared to JVM. Is there any claims from the team building Graal that it could match JVM as native binaries? Or get very close?
Yea I have this working already. There just isn't a good webview option. I don't like the JavaFX one
gotcha
its quite close and even better under some circumstances: https://medium.com/graalvm/graalvm-for-jdk-21-is-here-ee01177dd12d
I saw Thomas WĂĽrtingers talk at StrangeLoop last week where he showed graphs how graal native now beats the JVM jit on all operational metrics (memory + throughput) thanks to the new profile guided optimizations.
talk was great btw
So it sounds like it’s best to move on ideas with the assumption that a native binary will be the best option.
The way I see it is if your app has a long enough running time or always on, start with the JVM and measure the performance with native and then decide. If it has a short running time start native. There are caveats to native compilation. The talk I linked shows it. Not all code can be native compiled
Okay. I will watch talks. I am shipping a desktop app which is intended to be long running and doing a lot.
not needing a JVM might be nice for your users though
I was considering making it possible to do a webview like what Tauri offers.
But I would need to learn C and do the bindings etc. so it is a significant investment of time and I need to consider if it is worth it.
The idea is to have a locally running AI so people won’t mind something large with memory usage. But it’s silly to do that if native binary outperforms across all the metrics and I could just load into Tauri sidecar without doing the dive into C and all the work of creating bindings.
If you want your binary to perform as well as JIT for specific payloads, you should use PGO
I wouldn't start with optimizing though, just use -Ob or -O1 for less optimizations to first see if you can get stuff to work at all
Cool. Yea I'm more curious about horizon potentials so I can consider that in my work prioritisation and architecture decisions.
You could also just write your whole desktop app as a JVM app perhaps, e.g. with Niki's HumbleUI or plain JavaFX
Upgraded #babashka to Oracle GraalVM 21. A few things to watch out for:
• Use the /archive/ link instead of the /latest/ link to fetch a pinned version of GraalVM.
• Use -march=compatibility if you distribute your binary for public use (else you'll likely get "The current machine does not support all of the following CPU features that are required by the image", I ran into this)
• Use -O1 for similar outcomes as with GraalVM 22.3.0 CE (Note Oracle GraalVM 21 is newer, this version just follows the JDK version!): similar image size and compilation time. The default in Oracle GraalVM does more aggressive optimizations than CE, takes longer to compile and yields bigger images
• PGO is good way to optimize your binary for specific payloads. A loop with 10M took 600ms before, now 300ms, same as you would get with babashka on JVM JIT).
I see this https://blogs.oracle.com/java/post/oracle-graalvm-for-jdk-21
> To reduce application compile times, some optimization phases that were previously included in the default level 2 (-O2) have been moved to a new level 3 (-O3). The level 3 optimizations work best with profile guided optimization, so they are automatically enabled when compiling with --pgo. The result is faster default compilation times with no significant impact on application performance. PGO continues to employ the same optimizations as in previous releases.
I'm wondering if specifying --pgo is overwriting the -O1 with -O3 and makes a comparassion between with and without pgo not fair as one may be using -O1 and the other -O3, does that makes sense?
Sure, then compare with O3
Some good tips maybe for https://github.com/clj-easy/graal-docs
hmyeah