Linked by Peter Gerdes on Mon 10th Jan 2005 17:35 UTC
Editorial As a recent ACM Queue article observes the evolution of computer language is toward later and later binding and evaluation. So while one might quibble about the virtues of Java or the CLI (also known as microsoft.net) it seems inevitable that more and more software will be written for or at least compiled to virtual machines. While this trend has many virtues, not the least of which is compatibility, current implementations have several drawbacks. However, by cleverly incorporating these features into the OS, or at least including support for them, we can overcome these limitations and in some cases even turn them into strengths.
Permalink for comment
To read all comments associated with this story, please click here.
Re: JIT is faster than static compilation
by Deletomn on Tue 11th Jan 2005 03:38 UTC

(Note: I decided to address the C vs assembly comment first)

Anonymous (IP: ---.tm.net.my): In a similar way, assembly actually runs slower than C in a lot of cases because the C compiler can produce code that places the processor in a specific state, and the processor can easily predict what goes on from there and execute ahead.
A human can do by hand the same thing as the compiler. The only difference, is that it's easier to let the compiler do it. This is especially true if you are developing software for more than one platform or are new to the platform or the platform has some recent changes or if the software you're developing is especially complicated or if you don't have all the nessecary documentation for the platform, etc...

Anonymous (IP: ---.tm.net.my): The JIT and its runtime will always know far, far more about the executing state of the machine than a static compiler and can adapt accordingly.
Wrong. You can write a "static" program manually that will know everything about the computer it's running on and adapt, all you need to know are the appropriate instructions and techniques. (In fact, there are some optimizations that can be done manually that to my knowledge are still not done by any JIT.) And if you can do it by hand, then it's quite possible that a "static" compiler can be developed to do the same (or similar) thing.

The real advantages of a JIT are: 1) A program can be written a long long time ago and the JIT can still use the latest optimization techniques on it. Whereas if it was compiled with a "static" compiler, it's stuck with whatever optimization techniques were in use at the time. 2) A staticly compiled program needs to have all of it's optimizations "built-in" and that could take up alot of space. 3) If the optimizations are done by hand, that's going to require a fair (to alot) of effort, knowledge, and time just for the optimization, whereas with a JIT, it's all done for you. So you can focus more on simply making the program work.



However, I can say that I feel doing some optimizations by hand can be a big help. I've known of situations where the programmers found tons of bugs (and higher-level optimizations which the compiler couldn't do) simply by converting the program to assembly language by hand. The reason this helped is really quite simple, it provided them with a totally different perspective on the program and suddenly hard to find bugs (including ones which the programmers and debuggers had no idea existed) "suddenly appeared" and were "easily" eliminated.