←back to thread

Jank development update – Moving to LLVM IR

(jank-lang.org)
188 points refset | 3 comments | 15 Oct 24 06:50 UTC | HN request time: 0.61s | source
Show context
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 #
1. 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 #
2. 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 #
3. refset ◴[17 Oct 24 16:51 UTC] No.41871347[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/