A JIT can do all the optimisations that a static compiler can, and then of top of that it can do additional optimisations that a static compiler can't.
It's actually not that difficult to find programs where a JIT is better.
Things that benefit significantly from profile directed feedback often run faster in JIT than static compilers, because JIT's tend to do this dynamically, whereas static compilers require training runs.
For example performance critical code that has a lot of conditional branches, but only a few are taken at runtime, will often work faster in a JIT.
(Of course, the typical solution is not to write performance critical code with a large number of branches, i'm just giving you examples)
I assume that JITs don't do very expensive optimizations because they have to do a trade off between execution speed and compilation time. JITs are also fairly blind on the first execution of a piece of code. Static optimizations are not made obsolete by the existence of JITs.
JITs (as those found in V8, JSC, SpiderMonkey) can theoretically compile better code than static compilation approaches like C, C++, and Rust. It's because the runtime can collect information about what is being run and then generate code accordingly.
Wow I'd need some evidence to believe JIT can do a better job than a 'static' compiler. What can JIT do to optimize 'much more so'? How about a little more? If you know some common conditional jump stats you can do slightly better. Is there anything else?
People are often confused about how a JIT can be faster than a static compiler - this is a great example of why that can be the case. A dynamic compiler would be able to speculatively inline through the function pointer, where in a static compiler that is not tractable with what we currently know about compilers.
JITs don't have so much time to optimize, as static compilers do. Therefore, they can't do e.g. whole program analysis, or expensive cache related optimizations. Despite 15 years of effort of speeding up JVM, it is still slower in general than optimized C. Not by much (usually good Java code runs within a 2x slower margin), but still - it can't beat static compilers.
I admit that I stopped following compiler research a while back, but I doubt that a JIT compiler would use run-time behavior to beat a static compiler.
Do you have any reference or link to such optimization?
We have JIT compilers that can optimize "better" than static. People are still using the latter because there are other benefits that nobody from the ivory tower can beat.
JIT has potential to be faster than compiled native code. Better runtime information. Compiled code needs to cover all potential options and this means more instructions to execute.
Say a variable value is set through a command line option to be a certain value. Compiled native code has to assume the value to be dynamic, but a JIT can optimize it away, effectively hardcoding it for that particular invocation. Same applies to more complicated type of software. Some configuration and invocation parameters tend to be effectively static during that particular invocation. JITs can capitalize on this fact.
JITs have also better chance to adapt to exact hardware it's running on. Compiled code is forced to make one or a limited number of assumptions of available CPU hardware configuration.
In the end, both options are running compiled native code. JIT just does it a bit before running.
Of course current reality is the opposite, but the key word here is potential.
The JIT advantage is the runtime information. Only benchmarks will always run the code in same way. Any useful piece of software runs under different conditions in different invocations and situations.
JIT can remove code from inner loops that is unnecessary for the current invocation. It can also use any instructions available on the CPU it's running on. It can use more registers if the CPU has them.
JIT advantage is higher performance, which is mostly untapped today.
I don't care about winning any points. I just want people to understand it's not black and white. JIT as an acronym causes them to jump to conclusions without even thinking about it.
Statically compiled code is suboptimal for all but the idealized case the code was compiled for. It has to take general case into account. Wasting cycles checking the condition that's always false anyways for current problem. Setting up the inner loop that's executed just once or twice every time.
A JIT can spend a few microseconds optimizing for that and running the code for 10 milliseconds. Instead of running the generic statically compiled case for 20 milliseconds. JIT can produce code more native than the "native" statically compiled presentation.
If JIT-ing a statically compiled input makes it faster, does that mean that JIT-ing itself is superior or does it mean that the static compiler isn't outputting optimal code? (real question. asked another way, does JIT have optimizations it can make that a static compiler can't?)
reply