3 ms·

I've heard the exact opposite. The supposed performance benefits of JIT compared to AOT (profile-guided optimization, run-time uarch-targeted optimization) neve

I've heard the exact opposite. The supposed performance benefits of JIT compared to AOT (profile-guided optimization, run-time uarch-targeted optimization) never really materialized. There's been a lot of research since the late '90s into program transformation and it turned out that actually the most effective optimizations are architecture-independent and too expensive to be performed over and over again at startup or when the program is running. At the same time, deciding when it's worthwhile to reoptimize based on new profiling data turned out to be a much more difficult problem than expected. So the end result is that while both AOT (GCC, LLVM) and JIT (JVM, CLR) toolchains have been making gradual progress in performance, the JIT toolchains never caught up with the AOT ones as was expected in the '90s.

pjmlp 5y ago
Good luck with inlining and devirtualization across DLLs with AOT. JIT caches with PGO get most of AOT benefits, that is why after the short stint with AOT on Android, Google decided to invest in JIT caches instead. The best toolchains can do both, so it is never a matter of either AOT or JIT. GCC and clang aren't investing in JIT features just for fun.
- fluoridation 5y ago
  What's with the snappy tone? >Good luck with inlining and devirtualization across DLLs with AOT. An AOT compiler/linker is unable to inline calls across DLL boundaries because DLLs present a black-box interface. A JIT compiler would run into the exact same problem when presented with a DLL whose interface it doesn't understand or is incompatible with. If you really want a call inlined the solution is to link the caller and function statically (whether the native code generation happens at compile- or run-time), not to depend on unknown capabilities of the run-time. >The best toolchains can do both, so it is never a matter of either AOT or JIT. You're refuting a false dichotomy no one raised.
  - pjmlp 5y ago
    I am sarcastic by nature, that is why. JIT compilers for Java and .NET do inline across shared libraries and devirtualization, including native calls. When people discuss A vs B there is always a dichotomy.

pjmlp 5y ago

Good luck with inlining and devirtualization across DLLs with AOT. JIT caches with PGO get most of AOT benefits, that is why after the short stint with AOT on Android, Google decided to invest in JIT caches instead. The best toolchains can do both, so it is never a matter of either AOT or JIT. GCC and clang aren't investing in JIT features just for fun.

fluoridation 5y ago
What's with the snappy tone? >Good luck with inlining and devirtualization across DLLs with AOT. An AOT compiler/linker is unable to inline calls across DLL boundaries because DLLs present a black-box interface. A JIT compiler would run into the exact same problem when presented with a DLL whose interface it doesn't understand or is incompatible with. If you really want a call inlined the solution is to link the caller and function statically (whether the native code generation happens at compile- or run-time), not to depend on unknown capabilities of the run-time. >The best toolchains can do both, so it is never a matter of either AOT or JIT. You're refuting a false dichotomy no one raised.
- pjmlp 5y ago
  I am sarcastic by nature, that is why. JIT compilers for Java and .NET do inline across shared libraries and devirtualization, including native calls. When people discuss A vs B there is always a dichotomy.