3 ms·

What's the difference in practice between a JIT and an AOT compiler that supports optimizations based on runtime analysis (I forgot the technical term for that.

What's the difference in practice between a JIT and an AOT compiler that supports optimizations based on runtime analysis (I forgot the technical term for that. Profile-guided optimization, maybe?)? I think the real issue is, the higher level the language, the harder it is to reason about what your code will actually get compiled down to. If you want predictable performance in Java, or any high-level language, in my experience you have to essentially write C code in that language, or at least get as close as possible. In Java, that usually means: * sticking to primitives or arrays of primitives as much as possible. The language has no support for user-defined value types! * Sticking to regular for loops, while loops, and other similar control structures. * Using offheap memory via Unsafe or similar API when feasible.

jeffbee 4y ago
The things that most Java applications need to do to reduce the variance of runtime outcomes are sadly a little more basic: use a modern VM, set the compilation flags appropriately, and make sure the code caches are large enough to hold all your hot functions.
- PathOfEclipse 4y ago
  My experience leads me to the exact opposite conclusions. For example, your code cache is either big enough or it's not. It's a pretty binary situation and a simple checkbox to ensure your app didn't run out of space. To quote from https://stackoverflow.com/questions/7513185/what-are-reservedcodecachesize-and-initialcodecachesize https://stackoverflow.com/questions/7513185/what-are-reserve...: "Normally you'd not change this value. I think the default values are quite good balanced because this problems occur on very rare occasions only (in my experince)." Similarly, your organization tends to run the version of Java that the whole company supports. I have never worked anywhere where someone was allowed to use a different version than the rest of the company for performance reasons. In contrast, the advice to write low-level code for predictable, high performance has been virtually timeless and generally applicable across languages.
  - jeffbee 4y ago
    I'm not suggesting that devs should just wildcat a newer JDK, but surveys indicate that significant population of organizations are still on 8 or even 7. If that's your org, this is probably performance left on the table. As for the code caches, you're right that it's a binary outcome, but the signals are subtle and if you aren't looking at the right stats a non-expert without a good calibrated gut feeling for how good the performance should be might just conclude that the app was written poorly, or Java just sucks, or whatever.

jeffbee 4y ago

The things that most Java applications need to do to reduce the variance of runtime outcomes are sadly a little more basic: use a modern VM, set the compilation flags appropriately, and make sure the code caches are large enough to hold all your hot functions.

PathOfEclipse 4y ago
My experience leads me to the exact opposite conclusions. For example, your code cache is either big enough or it's not. It's a pretty binary situation and a simple checkbox to ensure your app didn't run out of space. To quote from https://stackoverflow.com/questions/7513185/what-are-reservedcodecachesize-and-initialcodecachesize https://stackoverflow.com/questions/7513185/what-are-reserve...: "Normally you'd not change this value. I think the default values are quite good balanced because this problems occur on very rare occasions only (in my experince)." Similarly, your organization tends to run the version of Java that the whole company supports. I have never worked anywhere where someone was allowed to use a different version than the rest of the company for performance reasons. In contrast, the advice to write low-level code for predictable, high performance has been virtually timeless and generally applicable across languages.
- jeffbee 4y ago
  I'm not suggesting that devs should just wildcat a newer JDK, but surveys indicate that significant population of organizations are still on 8 or even 7. If that's your org, this is probably performance left on the table. As for the code caches, you're right that it's a binary outcome, but the signals are subtle and if you aren't looking at the right stats a non-expert without a good calibrated gut feeling for how good the performance should be might just conclude that the app was written poorly, or Java just sucks, or whatever.