JIT vs AOT Compilation

jg21 writes "This article on "Penguin-Driven" JVMs takes a look the performance of Java GUI applications based on the JFC/Swing API, and contends that the JIT-powered JVMs can't match a JVM with an ahead-of-time compiler ported to the Linux/x86 platform. With AOT compilation, says the CTO who has written this piece, real-world Swing applications performed perceivably faster. One is left wondering, will we now see the 'microbenchmark war' carried into the Linux camp?"

Comments

What about dynamic compliation?

[Muda69]

IMO, this is the way to go. Dynamic compilation is a mix of interpretation and translation. It defers compilation for a body of code, until it believes that it will have an impact upon the runtime of the program. Dynamic compilation has the same benefits as JIT compilation, but mitigates the compilation times and pauses by limiting the amount of code it actually compiles. Additionally, dynamic compilation can take advantage of runtime characteristics of the program itself, allowing it to perform optimizations like monomorphic inlining. (Although it wouldn't be fair to elide the fact that AOT compilers could potentially make use of feedback/runtime profiling to achieve some of the same characteristics).

Re:What about dynamic compliation?

[mmusson]

One of the points in the article is that the JIT compilers did not do well with Swing code because it did not have hot spots. Any type of after the fact compile is not going to perform well if it can't identify the parts of the code that need to be compiled.

ibm's daisy

[ophix]

doesnt ibm have a project named daisy that is a JIT vm running on top of the very machine it emulates?

i seem to remember reading that they were able to achieve up to 25% performance increase by doing so (by taking advantage of run time profiling of the executable)

i might be mistaken though

Introspective behaviour

[12357bd]

Why not spend our ever increasing computing power to create 'introspective' programs? I mean programs that dinamically examines and changes program behaviour, looking for 'better' execution modes.

VM's are a perfect environment for that kind of programming, ie, why not feature a JVM that dinamically adjust/perfect bytecode execution methods on a program by program basis?.
The article spots something old, optimizing is not a one size fits all matter, what is good for a given case is bad for another.

As our procressing power increases, we can achieve that 'programming about programming' indirection level.

Re:Introspective behaviour

[arkanes]

I think what he's saying is caching some of that information across program invocations, so that the next time you invoke "wc -l" the JVM looks at its JIT cache and pulls up (depending on whats available or practical) the profiling information it has from the last run or the actual compiled code.

This seems obvious and I wonder why it's not widespread. Maybe it is and I just don't know it? Maybe the work of figureing out whether or not your cache is stale outweighs the benefits? Taken to it's logical conclusion, this ends up turning into AOT compilation, of course, so there's some point where the disadvantages outweigh the advantages...

Why Not Both?

[RAMMS EIN]

Why compare JIT against AOT? Why not have both?

AOT compilation makes for fast start up time and fast run time. JIT advocates claim that it can lead to better performance, as more optimizations can be performed with run-time information. So why not combine the two? Compile it before the first run, and further optimize it at run-time where appropriate. That way, you get the best of both worlds.