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 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 11:00 UTC

Anonymous (IP: (Assembly vs C Comment)
Yes... Yes... I know all that. However, there's one other thing to take into account. A human understands what the purpose (among other things) of the the program (or function) is, this sometimes becomes important, because some optimizations can be "obvious" to some humans and yet evade the best efforts of the compiler.

Granted, that doesn't always happen (perhaps not even often, I wouldn't have any statistics) but it is a possibility. And certainly it still requires a human who actually has some sort of skill at this.

Personally, in my opinion, the nice thing about optimizations done by the compiler, is that they are nice and easy and usually very good. So that you (the programmer) can focus on making the program work rather than worrying about every little point that might be inefficient. Optimizing a program properly and throughly can take quite some time. And then if you move it to another platform (or something else happens) you don't have to worry about having to rewrite all of your optimizations. The compiler will do it for you.

In addition, (as stated before) you need quite a bit of expertise in order to optimize a program well, and this requires research and experience. Once again, more time saved.

Anonymous (IP: And again I will say, the JIT and runtime will always know more about the executing state of the machine.
And once again... I will say no it won't. Not versus a properly written program. All options available to a JIT and runtime are available to a staticly compiled program. ALL OPTIONS There is not a single one which cannot be implemented with "some" effort. All techniques, all instructions, all data, everything is available. It could (possibly) be built into a static compiler. Certainly it can be done by hand. The advantage over doing it by hand is obvious, time, effort, and expertise. The advantage over static programs in general (including a compiler) is as I stated before, the static program will need to lug around everything it needs with it and of course it can't include optimizations which haven't been invented yet.

For example, a (simple) staticly compiled program can check it's status as it runs and see how some or all functions are used by keeping statistics. It can then modify function calls (or for really simple programs, function pointers) and change the function to different optimized functions (you could have 100,000 different variants of one function, though this would be excessively impractical)

More "advanced" static programs could actually go through and modify individual instructions. At this point, however, it becomes very impractical to do by hand (and thus things begin to fall apart) The reasons being obvious, it will be different for each processor, it requires a high level of expertise, difficult to write, difficult to test, etc.

And so on...

As I stated, the advantage over doing it by hand is time, effort, and expertise. (And obviously after a certain point practicallity) However, it is possible, which was my point and for all I know, some innovative programmers out there might have resolved these things staticly and might not be talking (because it's some "secret").

One thing they can't do is make the program add optimizations to itself, which it didn't know about at runtime. And as I said, it's going to have to haul all of it's stuff around with it and that's going to take a fair bit of space.

Anonymous (IP: We're not talking about self-tuning of the program's internal variables and what-not, IIS and SQLServer have been doing that for years.
Hmmm... As far as I know modifying individual instructions is quite a bit different from self-tuning a program's internal variables. (BTW... I've done some of these things to a small extent and I also know what I could have done but didn't have time to do.)

Anonymous (IP: People like to cite the overhead of dynamic compilers and runtimes as to affecting performance in a negative way. However, this 'overhead' actually makes it faster.
Overhead does not make things go faster. That's like saying that by dropping money on the ground I've become richer. Dropping money on the ground clearly makes me poorer. However, you can still have a net gain, because the action that caused the overheard allows you to do things you wouldn't be able to do. In the case of dropping money on the ground, I might now be able to pick up that wad of money "over there". Whether I actually made a net gain or not is completely dependent on how much that wad is worth versus the wad I used to have. (Of course, we also need to take into account the walking over there and the amount of energy it took to drop the first wad, plus the amount of energy it took to pick up the second wad.)

Anonymous (IP: It makes more sense when you go deeper and look at things like speculative execution and probabilities.
I know that, I just don't know what the actual probabilities are, because I've never done extensive real world testing with it myself. Things can be different between theory and reality you know. And things can vary from one system to another.

And I'd want extensive real world tests, I've seen too many big announcments from local "Java supporters" which actually didn't even apply to their own clients/company. (One comes to mind, someone was talking about how vastly superior Java is to C/C++ as far as portability goes. And his latest project was implemented in Java and I had the "pleasure" of seeing the results, about one half of workstations this program was supposed to go on didn't have a compatible JVM at the time, but they all had C/C++ compilers. Later, (as in a couple years later) those workstations were upgraded to machines that did have JVMs. Note the "Later" part.)

Note: I've got nothing against VMs and Java in general, I think in the long run (if nothing else) it will be great. But in my opinion alot of people are overly excited.