[gubby]

Agreed. As an existence proof, the optimising compiler for language X could realise that a for() loop that uses 95% of the actual runtime CPU has no side effects and can be removed. There may be some feature or property of language Y that makes that analysis impossible.

In the Java case, the JIT performs a runtime analysis. Without wanting to making any assertions about overall performance here, there exists a non-zero set of programs for which runtime optimisation is superior to static compiler analysis.

[superjan]

I can second this. C# has had AOT and JIT compilation for years, and the JIT is almost always faster. It is really hard to predict where to optimize, devirtualize and inline if you don’t know the runtime behavior. (Note AOT != ngen, I am talking about the AOT developed to Microsoft’s mobile efforts)

[pkolaczk]

Static compilers can do PGO as well. In practice though, the benefits of PGO in languages like C or C++ that rely on static dispatch are small enough that most people don't care, except for programs that are extremely performance sensitive (compilers, browsers, AAA games etc) where shaving off a few % can make a difference.

What JVM wins in PGO, it loses in other areas, and the end result is often still much slower.

[kaba0]

But if my understanding is correct, PGOs don’t help much with “speculative optimizations” — eg. Java can almost always elide virtual calls when only one actual class is loaded implementing an interface, reverting back to virtual calls on class load.

No matter PGO these and similar examples can’t be done without self-modifying code, while java with JIT is sort of that in a way.