Hacker News Reader

Comment by randomsearch | Hacker News Reader

Does native code execution outweigh the loss of JIT optimisation?

For big applications with high concurrency and long lifetimes where reducing working set sizes compared to available CPU cache sizes, it probably won't.

But for a lot of smaller applications, or applications where you need to do a lot of warm-up of the JIT/JVM to avoid issus on deploy, and CLI tools it will definitely be a net-positive.

If I understand it correctly JIT compiles down Hotspots to native code, so if the entire executable is already native it must be just as fast or faster.

There are some optimizations hotspot can do that substrate cannot

JIT compilation makes decisions on how to optimize the generated code based on run-time analysis the program. AOT compilation doesn't have access to that information, which can lead to slower code.

However, because AOT compilation isn't delaying the execution of the program, it is allowed to take much more time to optimize the output.

You can AOT compile with PGO (Profile Guided Optimization) though.

And if you can record profiling data from every machine the code will run on you might be able to be confident no JIT could do better, until a new processor (that is a compatible architecture to the executable) that wasn't available at the time of compilation comes around and JIT can still tune for things like cache sizes or processor features and the AOT executable is stuck not being able to take advantage of them.

Agreed, but there are ways around it.

For example, Android P will upload PGO data into the store, which is then distributed across all devices, and fed into the on-device AOT compiler.

I would argue that is still a JIT in the spirit of this discussion so far. That, or we need another term to disambiguate the cases of AOT(pre-distribution) and AOT(post-distribution)

It is called PGO.

Reply on news.ycombinator.com