4 ms·
You're forgetting that the whole idea is not to compile the same language better, but to compile different languages (that are supposed to offer better producti
by pron 8y ago
You're forgetting that the whole idea is not to compile the same language better, but to compile different languages (that are supposed to offer better productivity) to have similar performance to C. Obviously, languages such as Javascript or Ruby cannot possibly be compiled AOT with good performance, but even Java relies heavily on virtual dispatch, and a JIT can inline through virtual calls. Languages that don't rely on virtual dispatch as much will benefit less from a JIT.
Today, as we have both AOT and JIT compilers for Java, we can see that the JIT does, indeed, generate better code. By how much depends on your specific use-case.
> lost to poor cache discipline of VMs
What are you referring to? If you're talking about memory layout, then this has nothing to do with the VM and everything to do with the language design. The reason Java has little control over memory layout was that it didn't make much of a difference in the '90s; now it does, so Java is getting control of layout.
- cm2187 8y agoBut you don't need JIT for that. You need an intermediary language (ByteCode / MSIL). In a non-JIT world you would use ByteCode/MSIL libraries, and just before deploying, statically compile them for the platform they will be deployed to. JIT just means you are doing that step everytime the program runs (+/- caching) for every machine.
- pron 8y agoYou cannot efficiently compile ahead of time languages whose semantics heavily rely on dynamic dispatch. AOT profile-guided optimization would help, but it carries added effort (and still cannot be as aggressive if there is no possibility of deoptimization and recompilation by a JIT). Intermediate representation is completely irrelevant. Java now offers "deploy-time" AOT compilation, and the results are not as good as a JIT (YMMV).
- pjmlp 8y agoJava now offers "deploy-time" AOT compilation for free. It has been available since the early days in commercial JDKs and initially it was the deployment option on IBM mainframes, by converting JVM bytecodes into the bytecodes of the mainframe execution environments.