3 ms·

It doesn't matter for FizzBuzz, but in general JIT should really out-perform "native" statically compiled compilers on most real-world workloads. While there's

It doesn't matter for FizzBuzz, but in general JIT should really out-perform "native" statically compiled compilers on most real-world workloads. While there's a small penalty for the profiling JIT needs, there are massive gains for data and access dependent optimizations that static compilation can't achieve without explicit hints. For example, a JIT can observe the most commonly accessed data and re-order it to optimize for the pre-fetching pipeline. Or it can re-order operations to optimize for cache-line hotness.

pkolaczk 3y ago
> but in general JIT should really out-perform "native" statically compiled compilers on most real-world workloads. In theory, yes, but in practice I've never seen it happen. Best I ever saw was matching C speed at toy benchmarks. Even in this benchmark here, Java is decent, but does not beat even the naive implementations in C/Rust. Also, AOT compilers can do PGO as well, so they can use the same techniques. But they also have way more time and resources, so they can do things like whole program optimization, which is something JITs cannot do because they have much smaller computation and memory budget. It happened already many times to me that the first naive version of a C/C++/Rust program/function I wrote was already faster than a carefully tuned Java equivalent. AOT compilers for "fast languages" got really good these days. The design of language also influences how well it can be optimized by the compiler. E.g. it might look impressive JVM can devirtualize dynamic calls at runtime, but C++/Rust often don't have to do this at all as programs in those languages tend to have very few virtual calls if any at all.
- AlotOfReading 3y ago
  If you didn't need more evidence, the fact that the Java community has been slowly moving towards AoT with GraalVM should cement it. Java's JITs are damn impressive pieces of engineering, but the structural advantages of traditional compilation still win out surprisingly often.
  - jabradoodle 3y ago
    The move towards AOT is mostly for lower startup times and lower memory usage, not to make the application faster in general.
- DeathArrow 3y ago
  >Java is decent, but does not beat even the naive implementations in C/Rust. Java doesn't beat C in this benchmark but beats Rust with ease.
  - pkolaczk 3y ago
    There is not enough data to conclude that. There are 3 Java implementations slower than the faster Rust one, and there are 2 Java implementations faster. But there are only 2 data points for Rust in total. Also, technically there is nothing C can do that Rust can't.

pkolaczk 3y ago

> but in general JIT should really out-perform "native" statically compiled compilers on most real-world workloads. In theory, yes, but in practice I've never seen it happen. Best I ever saw was matching C speed at toy benchmarks. Even in this benchmark here, Java is decent, but does not beat even the naive implementations in C/Rust. Also, AOT compilers can do PGO as well, so they can use the same techniques. But they also have way more time and resources, so they can do things like whole program optimization, which is something JITs cannot do because they have much smaller computation and memory budget. It happened already many times to me that the first naive version of a C/C++/Rust program/function I wrote was already faster than a carefully tuned Java equivalent. AOT compilers for "fast languages" got really good these days. The design of language also influences how well it can be optimized by the compiler. E.g. it might look impressive JVM can devirtualize dynamic calls at runtime, but C++/Rust often don't have to do this at all as programs in those languages tend to have very few virtual calls if any at all.

AlotOfReading 3y ago
If you didn't need more evidence, the fact that the Java community has been slowly moving towards AoT with GraalVM should cement it. Java's JITs are damn impressive pieces of engineering, but the structural advantages of traditional compilation still win out surprisingly often.
- jabradoodle 3y ago
  The move towards AOT is mostly for lower startup times and lower memory usage, not to make the application faster in general.
DeathArrow 3y ago
>Java is decent, but does not beat even the naive implementations in C/Rust. Java doesn't beat C in this benchmark but beats Rust with ease.
- pkolaczk 3y ago
  There is not enough data to conclude that. There are 3 Java implementations slower than the faster Rust one, and there are 2 Java implementations faster. But there are only 2 data points for Rust in total. Also, technically there is nothing C can do that Rust can't.