4 ms·

Considering the time-limit of JIT compilation, I'd say almost certainly yes. AOT can analyze code basically forever (ask C++ compilers), so there's a whole clas

Considering the time-limit of JIT compilation, I'd say almost certainly yes. AOT can analyze code basically forever (ask C++ compilers), so there's a whole class of time-intensive optimizations that JIT simply cannot do. I'd personally always bet on AOT performance to beat JIT - to convince me otherwise is what I would require evidence for.

apignotti 3y ago
The tradeoffs are more subtle. A JIT compiler has more timing constraint, but more information about the runtime behavior of code. As a counter-point to your argument, consider a highly dynamic language such as JavaScript, in particular the '+' operator. An AOT compiler would have no choice but dispatch to a generic heavy implementation that could handle any possible combination of inputs. On the other hand a JIT compiler can observe the runtime values used and specialize using Inline Caches, potentially down to just a few instructions.
kaba0 3y ago
GraalVM native compiled binaries rarely beat out their JIT compiled counterparts - is that enough evidence? The time spent optimizing is more than enough when you can focus the resources for the actually relevant parts.
- garganzol 3y ago
  Probably depends on what you are optimizing for. If this metric is an app startup time then AOT is super beneficial and always beats JIT without strings attached.
  - kaba0 3y ago
    Well yeah, but that’s hardly a metric for performance.
    - koito17 3y ago
      Why is this being downvoted? I find it pretty clear that there is a trade off between startup time and performance. You can also observe this sort of behavior by tweaking -XX:TieredStopAtLevel when launching Java. You get marginally faster startup times but at the cost of run-time performance. And anecdotally I've seen native images start up faster but also have marginally slower runtime performance than launching a JVM and letting C2 do its thing.
- bheadmaster 3y ago
  > is that enough evidence? It's some evidence. Perhaps the HotSpot thing outperforms AOT on its own, it could be true. Somewhat equivalent to HotSpot but in AOT would be GraalVM's profile guided optimization. If runtime information is what brings JIT its advantage, then PGO could bring the same advantage to AOT. I don't have any hard data though.
- pjmlp 3y ago
  Only if PGO data is part of the compilation input. From GraalVM team themselves, https://youtu.be/sI-zXYLKzfk https://youtu.be/sI-zXYLKzfk
SigmundA 3y ago
Why is there a time limit? Doesn’t Java do multi tiered jitting with background compilation? Should be able to take as much time as needed in a background thread while code is executing in less optimized tier.
- kaba0 3y ago
  Java has 2 tiers, but even so it can’t take some unbounded amount of time doing every kind of analysis, as a big selling point of JIT compilers is optimizations based on assumptions, with some low chance of needing a de/reoptimization later. For what its worth, there is a vendor that uses LLVM as a JIT compiler (Falcon), but that really is not the bottleneck in most java applications.
  - pjmlp 3y ago
    OpenJDK has 2 tiers, other JVM implementations differ.

apignotti 3y ago

The tradeoffs are more subtle. A JIT compiler has more timing constraint, but more information about the runtime behavior of code. As a counter-point to your argument, consider a highly dynamic language such as JavaScript, in particular the '+' operator. An AOT compiler would have no choice but dispatch to a generic heavy implementation that could handle any possible combination of inputs. On the other hand a JIT compiler can observe the runtime values used and specialize using Inline Caches, potentially down to just a few instructions.

kaba0 3y ago

GraalVM native compiled binaries rarely beat out their JIT compiled counterparts - is that enough evidence? The time spent optimizing is more than enough when you can focus the resources for the actually relevant parts.

garganzol 3y ago
Probably depends on what you are optimizing for. If this metric is an app startup time then AOT is super beneficial and always beats JIT without strings attached.
- kaba0 3y ago
  Well yeah, but that’s hardly a metric for performance.
  - koito17 3y ago
    Why is this being downvoted? I find it pretty clear that there is a trade off between startup time and performance. You can also observe this sort of behavior by tweaking -XX:TieredStopAtLevel when launching Java. You get marginally faster startup times but at the cost of run-time performance. And anecdotally I've seen native images start up faster but also have marginally slower runtime performance than launching a JVM and letting C2 do its thing.
bheadmaster 3y ago
> is that enough evidence? It's some evidence. Perhaps the HotSpot thing outperforms AOT on its own, it could be true. Somewhat equivalent to HotSpot but in AOT would be GraalVM's profile guided optimization. If runtime information is what brings JIT its advantage, then PGO could bring the same advantage to AOT. I don't have any hard data though.
pjmlp 3y ago
Only if PGO data is part of the compilation input. From GraalVM team themselves, https://youtu.be/sI-zXYLKzfk https://youtu.be/sI-zXYLKzfk

SigmundA 3y ago

Why is there a time limit? Doesn’t Java do multi tiered jitting with background compilation? Should be able to take as much time as needed in a background thread while code is executing in less optimized tier.

kaba0 3y ago
Java has 2 tiers, but even so it can’t take some unbounded amount of time doing every kind of analysis, as a big selling point of JIT compilers is optimizations based on assumptions, with some low chance of needing a de/reoptimization later. For what its worth, there is a vendor that uses LLVM as a JIT compiler (Falcon), but that really is not the bottleneck in most java applications.
- pjmlp 3y ago
  OpenJDK has 2 tiers, other JVM implementations differ.