3 ms·
GraalVM native compiled binaries rarely beat out their JIT compiled counterparts - is that enough evidence? The time spent optimizing is more than enough when
by kaba0 4y 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 4y agoProbably 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 4y agoWell yeah, but that’s hardly a metric for performance.
- koito17 4y agoWhy 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 4y 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 4y agoOnly if PGO data is part of the compilation input. From GraalVM team themselves, https://youtu.be/sI-zXYLKzfk https://youtu.be/sI-zXYLKzfk