4 ms·

Hotspot performs inlining + DCE/CSE/costant folding/... in a loop, they call it incremental inlining. I.e. inline, eliminate, now you have new inlining opportun

Hotspot performs inlining + DCE/CSE/costant folding/... in a loop, they call it incremental inlining. I.e. inline, eliminate, now you have new inlining opportunities because the code dropped below your max inlining size, rinse & repeat. I think rustc does not iterate llvm optimization passes and thus even with lto leaves opportunities on the table.

kllrnohj 7y ago
> I think rustc does not iterate llvm optimization passes and thus even with lto leaves opportunities on the table. I think you'd need to support that with some evidence. If there's any code that hotspot manages to out-optimize LLVM on that'd be a fascinating investigation. In practice I think you'll be shocked how well GCC & LLVM make code vanish vs. Hotspot. It's one of the major reasons benchmarking C/C++ code is so damn hard, the optimizer tends to eliminate the entire thing.
- pron 7y ago
  > In practice I think you'll be shocked how well GCC & LLVM make code vanish vs. Hotspot. First of all, HotSpot is a VM, not a compiler. It has several compilers, among them C2 (the default optimizing compiler), Graal, but also LLVM (Zing is a HotSpot fork VM which uses an LLVM-based JIT called Falcon: https://www.azul.com/products/zing/falcon-jit-compiler/ https://www.azul.com/products/zing/falcon-jit-compiler/) + several GCs + other stuff. Second, I think you may be shocked at the comparison of LLVM to C2: https://youtu.be/O87PaWkXlZ0 https://youtu.be/O87PaWkXlZ0 (they come up about the same, each winning/losing on different things). And that is when the optimization can be proven; whatever optimization you have, a JIT can apply them more aggressively.
- the8472 7y ago
  Note that it is up to the compiler frontend to choose which LLVM optimization passes to call, in which order and how often. But neither clang[0] nor rustc[1] do something that resembles hotspot C2's incremental inlining[2]. It is fairly expensive, so hotspot's benefit here is that it only has to spend the optimization cycles on the hottest code. > It's one of the major reasons benchmarking C/C++ code is so damn hard, the optimizer tends to eliminate the entire thing. This is totally a thing in java too. That's why the java microbenchmark harness (JMH) provides helpers that can inhibit DCE, constant propagation and inlining [0] https://www.youtube.com/watch?v=s4wnuiCwTGU https://www.youtube.com/watch?v=s4wnuiCwTGU [1] https://github.com/rust-lang/rust/issues/44041 https://github.com/rust-lang/rust/issues/44041 [2] https://bugs.openjdk.java.net/browse/JDK-8005071 https://bugs.openjdk.java.net/browse/JDK-8005071
- pjmlp 7y ago
  Here are two examples, inlining method calls and flatning object hiearchies across dynamic libraries. AOT LTO always loses against dynamic linking, whereas a JIT has free reign on that area.

kllrnohj 7y ago

> I think rustc does not iterate llvm optimization passes and thus even with lto leaves opportunities on the table. I think you'd need to support that with some evidence. If there's any code that hotspot manages to out-optimize LLVM on that'd be a fascinating investigation. In practice I think you'll be shocked how well GCC & LLVM make code vanish vs. Hotspot. It's one of the major reasons benchmarking C/C++ code is so damn hard, the optimizer tends to eliminate the entire thing.

pron 7y ago
> In practice I think you'll be shocked how well GCC & LLVM make code vanish vs. Hotspot. First of all, HotSpot is a VM, not a compiler. It has several compilers, among them C2 (the default optimizing compiler), Graal, but also LLVM (Zing is a HotSpot fork VM which uses an LLVM-based JIT called Falcon: https://www.azul.com/products/zing/falcon-jit-compiler/ https://www.azul.com/products/zing/falcon-jit-compiler/) + several GCs + other stuff. Second, I think you may be shocked at the comparison of LLVM to C2: https://youtu.be/O87PaWkXlZ0 https://youtu.be/O87PaWkXlZ0 (they come up about the same, each winning/losing on different things). And that is when the optimization can be proven; whatever optimization you have, a JIT can apply them more aggressively.
the8472 7y ago
Note that it is up to the compiler frontend to choose which LLVM optimization passes to call, in which order and how often. But neither clang[0] nor rustc[1] do something that resembles hotspot C2's incremental inlining[2]. It is fairly expensive, so hotspot's benefit here is that it only has to spend the optimization cycles on the hottest code. > It's one of the major reasons benchmarking C/C++ code is so damn hard, the optimizer tends to eliminate the entire thing. This is totally a thing in java too. That's why the java microbenchmark harness (JMH) provides helpers that can inhibit DCE, constant propagation and inlining [0] https://www.youtube.com/watch?v=s4wnuiCwTGU https://www.youtube.com/watch?v=s4wnuiCwTGU [1] https://github.com/rust-lang/rust/issues/44041 https://github.com/rust-lang/rust/issues/44041 [2] https://bugs.openjdk.java.net/browse/JDK-8005071 https://bugs.openjdk.java.net/browse/JDK-8005071
pjmlp 7y ago
Here are two examples, inlining method calls and flatning object hiearchies across dynamic libraries. AOT LTO always loses against dynamic linking, whereas a JIT has free reign on that area.