Hacker News Reader

Comment by vlovich123 | Hacker News Reader

I wonder if how much value there is in skipping LLVM in favor of having a JIT optimized linked in instead. For release builds it would get you a reasonable proxy if it optimized decently while still retaining better debugability.

I wonder if the JVM as an initial target might be interesting given how mature and robust their JIT is.

View on HN

> I wonder if how much value there is in skipping LLVM in favor of having a JIT optimized linked in instead. For release builds it would get you a reasonable proxy if it optimized decently while still retaining better debugability.

Rust is in the process of building out the cranelift backend. Cranelift was originally built to be a JIT compiler. The hope is that this can become the debug build compiler.

https://github.com/rust-lang/rustc_codegen_cranelift

I recently tried using cranelift on a monorepo with a bunch of crates, and it is nothing short of amazing. Nothing broke and workspace build time went from a minute and a half to a half of a second!

Was this for a release build or a debug build?

Cranelift is only intended for debug builds, there is nothing stopping you from using it for release builds but — to the best of my knowledge — you get noticeably degraded runtime performance if you go that way.

The JVM is not a very meaningful target for Rust since it does not use C-like flat memory addressing and pointer arithmetic. It's as if every single Java object and field is sitting in its own tiny memory segment/address space. On the one hand, this makes it essentially transparent to GC, which is a key property for Java; OTOH, it means that compiling C-like languages to the JVM is usually done by reimplementing "memory" as a JVM array of byte values.

LLVM optimizations are the overwhelming majority of the compilation bottleneck for us over at Feldera. We blogged about some of the challenges we faced here: https://www.feldera.com/blog/cutting-down-rust-compile-times...

We almost definitely need to build a JIT in the future to avoid this problem.

I would love this in modern languages.

For dev builds, I see JIT compilation as a better deal than debug builds because it's capable of eventually reaching peak performance. For performance sensitive stuff like games, it really matters to keep a nice feedback loop without making the game unusable by turning off all optimizations.

AOT static binaries are valuable for deployments.

No idea how expensive it would be to develop for an existing language like Rust though.

That approach is what you get in Common Lisp, Eiffel, Oberon language family, Java, .NET, Julia (getting there), Haskell, OCaml, C++ (with something like ROOT or C++/CLI).

So if enough people care for Rust, it is also possible.

Reply on news.ycombinator.com