3 ms·

> You could probably make the claim that static optimization is a halting problem, and dynamic optimization eventually can beat it by definition since it can op

by m0th87 13y ago

> You could probably make the claim that static optimization is a halting problem, and dynamic optimization eventually can beat it by definition since it can optimize what the program is actually doing. It's not as if static type systems and JIT compilation are mutually exclusive concepts, so this argument makes no sense. If JITing were a panacea, dynamically typed languages would be just as fast as statically typed, and lower-level languages like C would be long dead. This is clearly not the case.

mwcampbell 13y ago
I think his point there is that a JIT compiler can handle dynamism more effectively than an AOT compiler. A corollary is that the more static the language is, the less advantage JIT compilation has over AOT compilation.
- PommeDeTerre 13y ago
  Part of what I see m0th87 saying, though, is that practice has shown that these claims about JIT compilation handling certain cases more effectively than AOT compilation just don't really hold true. JIT compilation may be better than some of the other approaches for implementing VMs or interpreters. It may also theoretically have the potential to be better than AOT compilation in some cases, too. But that potential doesn't really matter if we never see such benefits in real systems. Real-world code written in C, C++, and Fortran and compiled ahead of time still basically always outperform Java bytecode executed by HotSpot, or JavaScript code executed by V8, or Lua code executed by LuaJIT, by a huge margin. This is even after a huge amount of effort has gone into systems like HotSpot and V8, for instance. The theoretical benefits of JIT compilation do us no good if it's too costly or difficult to build effective implementations of such systems in a timely manner, for example. It does the wider community no good if such optimizations only really apply in a very small number of highly specific cases, as well. A lot of us have heard these claims about JIT compilation for over a decade now, especially with respect to HotSpot, but we've yet to see these techniques consistently and reliably match AOT compilation in general, never mind outperform it. There is a lot of doubt out there due to this.
  - simula67 13y ago
    As much as I like C, it would be better if language choice does not depend on the performance it can deliver. It would be nice to see the JVM pull up closer to AOT compiled languages, but as this post painfully exposes, this seems implausible.
nickik 13y ago
I think there where C Jit but the did not win out for some reason. My think is, if we today would try to do a C jit with GCC resources it would probebly be just as fast. There is simply nobody working on lowlevel language JITs.

by m0th87 13y ago

mwcampbell 13y ago

I think his point there is that a JIT compiler can handle dynamism more effectively than an AOT compiler. A corollary is that the more static the language is, the less advantage JIT compilation has over AOT compilation.

PommeDeTerre 13y ago
Part of what I see m0th87 saying, though, is that practice has shown that these claims about JIT compilation handling certain cases more effectively than AOT compilation just don't really hold true. JIT compilation may be better than some of the other approaches for implementing VMs or interpreters. It may also theoretically have the potential to be better than AOT compilation in some cases, too. But that potential doesn't really matter if we never see such benefits in real systems. Real-world code written in C, C++, and Fortran and compiled ahead of time still basically always outperform Java bytecode executed by HotSpot, or JavaScript code executed by V8, or Lua code executed by LuaJIT, by a huge margin. This is even after a huge amount of effort has gone into systems like HotSpot and V8, for instance. The theoretical benefits of JIT compilation do us no good if it's too costly or difficult to build effective implementations of such systems in a timely manner, for example. It does the wider community no good if such optimizations only really apply in a very small number of highly specific cases, as well. A lot of us have heard these claims about JIT compilation for over a decade now, especially with respect to HotSpot, but we've yet to see these techniques consistently and reliably match AOT compilation in general, never mind outperform it. There is a lot of doubt out there due to this.
- simula67 13y ago
  As much as I like C, it would be better if language choice does not depend on the performance it can deliver. It would be nice to see the JVM pull up closer to AOT compiled languages, but as this post painfully exposes, this seems implausible.

nickik 13y ago

I think there where C Jit but the did not win out for some reason. My think is, if we today would try to do a C jit with GCC resources it would probebly be just as fast. There is simply nobody working on lowlevel language JITs.