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).

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.

1998 called

[p3d0]

They want their idea back.

Let me clarify

[p3d0]

If you can show me a commercial JIT compiler that doesn't already do this, I'll eat my hat. What you call "dynamic compilation" is so routine and mundane that when people talk about "JIT compilers" these days, that is exactly what they are talking about. Nobody blindly compiles on the first invocation of a method any more.

What you have mentioned is not the crux of the problem. I can't say much more because I do confidential work on IBM's JIT compiler.

Re:Let me clarify

[p3d0]

Yes, I have actually done this myself for x86 with my pet language's interpreter/compiler, so I'm not just talking out my arse.

Oh, ok. For a moment there, I thought I was a professional JIT developer, but apparently I was mistaken.

Re:What's the point in Java bytecode anyway?

[p3d0]

It is parse trees. It's stack-based, which is pretty much just a post-order traversal of expression trees. Think of bytecode as a file format for describing expression trees.

Augh! Are they TRYING to drive me insane?

[Sentry21]

When will the TLA madness end? Oh, the humanity! At least provide definitions, for those god-fearing folk who may be interested but not up-to-date.

JVM: Java Virtual Machine, the virtual environment that every Java bytecode program runs within, abstracting real hardware for the program in question.

GUI: Graphical User Interface

JFC: Java Foundation Classes - the basic classes that are provided to developers upon which, or rather, with which, to build their programs.

API: Application Programming Interface, a defined way for software to interface with other software (i.e. to make library calls)

JIT: Just-In-Time compilation, compiles the program when it is being launched, for the machine it is being launched on, in order to prevent poor performance by compiling every instruction whenever it needs to be done

AOT: Mentioned in the article text, it means Ahead of Time. For details, read the linked story.

CTO: Chief Technology Officer. Name given to an executive in charge of new or current technology.

Now that you know what is going on, RTFA.

--Dan