In general, when developers try to explain why (highly tuned) C++ is about 2x faster than Java, they mention that one factor is that C++ AOT compilation has much more time to do extensive optimizations than JIT. So I assumed that the AOT compilation in Graal would have similar opportunities so that even if it's not as fast as C++, it would be at least faster than JIT compilation -- however, this does not seem to be the case. Why is that? In particular, are there specific scenarios where Graal's AOT compiler would be faster? And conversely, are there cases when JIT will be faster than GRAAL AOTr? (This way, I can make an informed decision as to how useful it might be once I fully built my solution)?
1 Answers
one factor is that C++ AOT compilation has much more time to do extensive optimizations than JIT.
This is not really an issue. The JIT can take as long at optimizing as it wants, and do multiple incremental compilation runs as well. This can be done in a background thread.
What it really comes down to is: information. Highly tuned C++ is fast because the developer who wrote it used all the information available to optimize the code. This means being able to make more assumptions or do clever optimization tricks, and the C++ language allows you to tweak all the optimization knobs.
The JIT does it's best of course, but it doesn't necessarily have all the information about a particular piece of code that a developer would have, because it's a more general optimizer. For some cases the JIT also has compiler intrinsics, which are basically hand tuned replacements for certain methods and code patterns. Again, this is the developer taking advantage of superior knowledge about a certain situation to do optimizations.
However, with plain Java AOT it's really the opposite; Because the AOT compiler runs ahead of program execution, it has less information about the environment the program runs in, and no profiling information, and because of that it can do less good optimization.
Related