Talk:Just-in-time compilation

From Wikipedia, the free encyclopedia

This page is redundant with dynamic translation. Can they be merged? --FOo 04:01, 4 May 2004 (UTC)

Obfusco|FOo]] 12:54, 26 Apr 2005 (UTC)

I think there's some overlap with dynamic compilation and dynamic recompilation, too. I'm not sure how this would best be handled. --StuartBrady (Talk) 19:44, 2 March 2007 (UTC)

[edit] A note on interpretation

Just a comment for future reference: Pure interpreted systems are pretty damn rare these days. Earlier versions of this article held that JIT was a hybrid between interpreters and compilers, and implied that "scripting languages" were typically slow and impractical interpreters. This is inaccurate. With the exception of shells such as bash, old-school interpreters are not so common. Most so-called "interpreted" "scripting" languages (usually an erroneous name) are bytecode compilers -- e.g. Perl and Python. I think it's more likely useful to consider JIT as a bridge between bytecode systems (like these and early JVMs) and full native-code dynamic compilers (like most Common Lisp systems for instance). --FOo 12:54, 26 Apr 2005 (UTC) jjjj


In the first paragraph a sentence starts with "In a bytecode-compiled system such as Perl, GNU CLISP, or early versions of Java,..." This leads to the impression that actual versions of Java were somewhat different. Either parting early and current versions of Java or the use of the term "bytecode-compiled system" is misleading. Regards 145.254.68.190 20:41, 24 August 2005 (UTC)

[edit] Performance?

Thanks to the article, I finally have a better appreciation of JIT, but one thing I've always always heard remains unexplained: performance. I've heard a number of proponents of JIT claim that it is fast, drawing a comparison of JIT and traditionally compiled code (i.e. to machine language).

I'm not sure I get it. I've yet to meet a developer that thinks that compile time is an important code performance metric, so I rule out the comilation to bytecode as the basis of comparison. That just leaves the dynamic translation, as far as I can tell. Since this is merely a bunch of lookups, I can see that this could be fast. But surely machine code is faster, since it requires no translation at all?

What am I missing?

If you can deliver compiled machine code, that's going to be faster to run than delivering bytecode and dynamically compiling (JIT) at runtime, yes. But if the system demands delivering bytecode, then JIT is faster than a bytecode-interpreting virtual machine.
As I understand it, in the Java case the deliverable is usually bytecode that could be deployed onto any architecture, relying on the virtual machine (whether interpreter or JIT compiler) to run it on the actual deployed system.
The Lisp case is a little different. The language requires (and some applications use) the ability to create new functions at runtime. For instance, the user might enter some parameters or expressions that the application would then build into a function. A dynamic compilation environment means that dynamically created functions get compiled to machine code and optimized as they are created -- a major improvement over running dynamically entered code in an interpreter! --FOo 03:30, 26 September 2005 (UTC)
It may well even be faster than machine code. See HP's Dynamo for details -- it can run PA/RISC programs on PA/RISC hardware faster than running them natively, sometimes by 20% or more. Basically, the set of optimizations you can do at compile-time and the set of optimizations you can do at run-time are quite different. At runtime, you could inline a shared library call, for example. It's really the same reason a JIT runs bytecode faster, except in this case, you have the overhead of an interpreter for non-hot-spots; as long as the performance gain from the optimizations (which accounts for most of the running time) outweighs the overhead of the interpreter, you win.
Maybe some notes should be made about the acronym JTL (Just Too Late). Form example http://www.thescripts.com/forum/thread16854.html —Preceding unsigned comment added by Doekman (talk • contribs) 12:27, 16 October 2007 (UTC)
Not unless somebody has a reliable source for this usage. I had a quick look, and it didn't seem particularly common, and mainly seems to have been used by one guy in various forums.WolfKeeper 00:30, 31 October 2007 (UTC)