Comment by pcwalton | Hacker News Reader

Comment by pcwalton | Hacker News Reader

Parent Full thread

> This is much faster than C# or Java, which compile to an intermediate interface (CLR and java bytecode respectively, which then run in a VM)

No. Both C# and Java use JITs, and their JITs have been carefully tuned to focus on hot spots. By not having a JIT, Go (in the 6g/8g/gccgo implementations) loses some important optimizations that are very helpful for making virtual-heavy languages like Go faster. JITs enable on-stack replacement, bailouts, and self-modifying code, which enable speculative devirtualization and (polymorphic) inline caching, just to name two techniques. These are very important optimizations that generally you can only get reliably in an ahead-of-time setting with profile-guided optimization, which Go 6g/8g don't have (and PGO is kind of a worse version of what good JITs do anyway).

The true benefits of AOT are reduced startup time and a greater tolerance for slower compilation, allowing for more sophisticated compiler optimizations—instruction scheduling, alias analysis, range analysis, etc. But Go 6g/8g are focused on fast compilation and omit most of those optimizations anyway.

> By not having a JIT, Go loses some important optimizations that are very helpful for making virtual-heavy languages like Go faster.

How does Rust work in this regard? By avoiding virtualization, and compiling each function to many specialized variants corresponding to each possible permutation of input and output types?

With generics, yes, like C++ templates: each combination of parameters results in one instance.

However, you can opt into using trait objects instead, which do use virtual calls.

Is pcwalton saying that a JIT compiler is more adequate for a "virtual-heavy" language like Go (to use devirtualization with inline caching and bailout), and an AOT compiler is more adequate for languages like Rust and C++ that mostly use code specialization?

It's not quite as clean-cut as that, though it is self-evident that optimizing at runtime (e.g. JIT) is the only recourse for optimizations that are otherwise reliant on runtime information (e.g. dynamic dispatch/virtual calls). Go does have an advantage over Java in that it prefers static semantics (pcwalton's assertion that Go is "virtual heavy" should likely be taken as relative to Rust/C++), so has less to benefit from devirtualization, and thus less of an argument to go the JIT route (which would take monumental engineering effort).

I believe pcwalton's points are that 1) running in a virtual machine does not imply that a language is slow (though I bet he'd agree with you that JIT introduces substantial memory overhead), and 2) Java, specifically, is not slow, thanks to a highly-tuned JIT.

Thanks! That's exactly what I wanted to know.

You forgot to mention a significant another drawback of most JIT implementations, compared to AOT: the bigger memory footprint.

Reply on news.ycombinator.com