Hacker News Reader

Comment by pjmlp | Hacker News Reader

Fully agree, JIT makes sense in dynamic languages or real-time conversion of op-codes, for everything else AOT is much better solution.

Having already quite a good experience with memory safe languages when Java came into the world (mostly Wirth and ML derived languages), I never understood why Sun went with the JIT approach. Other than trying to sell Java to run in the browser.

There were already quite a few solutions using bytecodes as portable executable format that were AOT compiled at installation time, e.g. mainframes and research OSes like Native Oberon variants.

The best is to have both on the toolchain. A interpreter/JIT for development and REPL workflows. Leaving the AOT for deployment/release code.

View on HN

> for everything else AOT is much better solution

Not if everything else includes long-running servers that may require various kinds of fiddling at runtime, like injection or turning off and on of monitoring/troubleshooting code, nor if you want to have zero-cost abstractions that are actually high-level abstractions (as opposed to the other kind of zero-cost abstractions, that are basically just weak abstractions that can be offered for free).

Once upon a time I did drank too much of JIT Kool-Aid, and for a moment I though it was the future, kind of.

However bearing the scars of the pain of "kinds of fiddling at runtime, like injection or turning off and on of monitoring/troubleshooting code" actually means in practice, changed my mind.

It is so damn hard to tune them, that there are consulting companies that specialize in selling JIT tunning services.

And in the end they offer little performance advantage over using PGO or writing code that makes better use of value types and cache friendlier algorithms.

This was one reason why Microsoft introduced PGO for .NET in .NET 4.5.

So yes, I really mean everything else.

I've gone the opposite way, and I really like my long-running server code to be JITted when possible. I only wish my old C++ servers could be tweakable at runtime as my Java servers[1] and I really like being able to use languages (even for DSLs or rule engines) that have a few powerful abstractions, and let the JIT make them run nearly as fast as the infrastructure code.

If you really need careful tuning of optimizations (which is never a walk in the park), it will be made much nicer with this: http://openjdk.java.net/jeps/165

[1]: Just like Erlang, only fast! ;)

It is possible to have powerful abstractions, AOT and performance.

One just has to look at Haskell, OCaml, Common Lisp, Ada, Eiffel, SPARK, Swift, .NET Native,....

The fact that for the last decade mainstream AOT was reduced to C and C++, kind of created the wrong picture that one cannot have performance in any other way.

I always dislike how they present some of the language features (stack allocation, structs and arrays) as if there wasn't any other language with them.

For monitoring, although one doesn't get something as nice as VisualVM or JITWatch, it is possible to bundle a mini-monitoring library if really needed.

Something akin to performance counters in Windows.

Ada (/SPARK) is a complex language that makes the developer think of every optimization-related implementation detail as they code (not unlike C++ or Rust), and Haskell/OCaml would benefit if functions that do pattern-matching could be inlined into their call site and all of their branches removed but one or two (the same goes for the other languages on the list).

I guess we will have to agree to disagree.

Just to provide some feedback that I should have written on the sibling comment.

I use both Java and .NET since they got out, there is the occasional C++ library, but they are the core of my work. So I know quite well their eco-systems.

Some of the mentioned scars were related with replacing "legacy" C++ systems, while keeping a comparable performance.

> Fully agree, JIT makes sense in dynamic languages or real-time conversion of op-codes, for everything else AOT is much better solution.

[Citation needed]

I don't need to cite other persons to be confident of my own opinion.

Reply on news.ycombinator.com