←back to thread

Jank development update – Moving to LLVM IR

(jank-lang.org)
188 points refset | 6 comments | 15 Oct 24 06:50 UTC | HN request time: 0.241s | source | bottom
1. mightyham ◴[17 Oct 24 11:34 UTC] No.41868615[source]▶
I'm curious what advantages Jank has over GraalVM, since Graal also supports interop with llvm languages.
replies(3): >>41869093 #>>41869221 #>>41871955 #
2. amelius ◴[17 Oct 24 12:39 UTC] No.41869093[source]▶
Maybe there are legal benefits because it's not from Oracle?
3. refset ◴[17 Oct 24 12:54 UTC] No.41869221[source]▶
Jank should be able to produce significantly smaller binaries than Graal native images at the very least, but the potential for performance gains looks to be rather large, e.g. per "jank has been consistently beating Clojure in benchmarks" [0]

[0] https://jank-lang.org/blog/2023-07-08-object-model/

replies(1): >>41870577 #
4. mightyham ◴[17 Oct 24 15:30 UTC] No.41870577[source]▶
That makes sense that the potential for performance improvements is greater, I'm just a bit skeptical it can actually "consistently beat clojure" in anything except for micro-benchmarks. It's mentioned in that article that jank uses a pretty basic GC while the JVM/Graal contains multiple state-of-the-art GCs tailored to different use cases. It's been shown many times that the JVM or Graal's JIT compiler have better peak performance over a long duration than compiled programs. This simply comes down to the fact that there are a host of specialized optimization strategies only possible when compilation can happen during runtime.
replies(1): >>41871347 #
5. refset ◴[17 Oct 24 16:51 UTC] No.41871347{3}[source]▶
> there are a host of specialized optimization strategies only possible when compilation can happen during runtime

That's a big part of why Jank is interesting to me, because it can properly embrace the idea of runtime JIT using LLVM. The JVM may still have an edge with profile-guided optimization for the foreseeable future, but perhaps Jank can help close that gap and support even more advanced possibilities for data-intensive workloads, e.g. along the lines of https://www.lingo-db.com/

6. Jeaye ◴[17 Oct 24 17:56 UTC] No.41871955[source]▶
With Graal native images, JIT compilation is not an option any longer. The runtime is static. With jank, you have a native binary, but you can JIT compile code with it and interop seamlessly with the native world. jank will also have an option for static runtimes, with no JIT compilation support, which can perform direct linking, better inlining, and whole program LTO. These builds will be smaller and lighter than native images.

Already, jank is faster than native images in the benchmarking I've done. The largest benchmark, so far, was a ray tracer.