But JIT is faster…
One of the arguments from people who recommend Java or the CLR is that the just in time compilation of a program means that it can take the use of an application into account and optimise the code generated towards that goal. Part of this idea comes from the HP Dynamo project. My personal theory is that because JIT interpreters are dealing with a full program they can do global optimisations, where normal compilers get feed one source file at a time, and therefore they cannot do the optimisations that the JITers can do. From personal experience I’ve discovered that flagging functions “static” in C means that gcc will do a much much better job at optimising them, as it knows that it knows everything it needs to about that function. Linkers that do Link time optimisations seem to be able to get similar sounding benchmarks.
So, my hypothesis is that writing a language in such a way that global optimisations can be done easily, or designing compilers so that they can take advantage of global optimisations will rival code able to be produced by the JITers.
September 29th, 2004 at 9:49 pm
the war. Garbage collection - Dynamic Garbage collection vs static garbage collection. But JIT is faster… - A look at why JIT is considered faster, and […]
September 30th, 2004 at 8:32 am
I always thought that one of the reasons that doing JIT compiliation was faster was that it would optimise the standard libraries as well. Which would mean that you would have to statically link every binary to get the full advantage of static optimisation. Sure hard disks are large enough to do that these days, but what about loading times or RAM consumption?
September 30th, 2004 at 6:27 pm
Right, but if you care that much about speed, you don’t mind statically linking for the added benefit. If you don’t care that much about speed, then living with what you’ve got is well, not that hard either.
October 5th, 2004 at 1:50 am
So how is this a counterargument against JIT? You’re saying static compilers can rival JIT given equal conditions. And indeed, they probably can. And the conclusion is.. what?
Even so, I don’t see the point in arguing this at all, anyway. No compiler used in practice goes directly from highlevel language source to machine code. It is always easier to write a compiler for a simple hypothetical machine’s P-code rather than one that goes directly to the platform’s native machine code. It is also much easier to write a translator that turns P-code to native machine code than to write a compiler that goes from highlevel source to native machine code.
So in practice, you always compile toward an intermediate machine anyway. Exactly what difference does it make whether the second step happens statically at compile-time or dynamically at run-time?