有没有人研究过 JIT 编译器的好处？

Question

请不要把这变成另一场关于 JIT 比静态编译好还是坏的战争。

关于静态编译与 JIT 编译的争论已经不胜枚举了。就个人而言，我倾向于静态编译，但这确实是问题所在。虽然从理论的角度来看，JIT 编译具有各种优势，但我还没有看到任何证据证明这些优势是可能实现的——也就是说，据我所知，这些优势仍只是理论上的。据我所知，没有人对当前状态进行过研究，我们所能做的就是使用我们有偏见的猜测并更深入地挖掘我们的战壕，还有另一组语言被滥用或被滥用的基准测试完全无关紧要。

要回答这个问题，我真的需要回答两个（或三个）问题：

1. 有没有人做过可信的研究来检查 JIT 编译器的状态
2. 有没有人做过可靠的研究来检查静态编译器的状态
3. 有没有人做过可信的研究，比较 JIT 编译器状态的研究和静态编译器的研究结果

最近的研究比任何几年前的研究都更有价值。

直接比较可能是不可行的，但只有两项具有真实经验证据的真实研究会很好；我意识到这可能是不可能实现的，至少在大多数人会同意结果的程度上。我知道benchmarking game，我怀疑这是我们已经或将要进行的最接近真实研究的。

Answer 1

没有JIT语言，但是有很多JIT语言实现。

编程语言是某种技术报告（通常用英语编写）中的规范（该语言的）。

编程语言规范的一个很好的例子是R5RS（Scheme 的一些变体）。您可以找到该语言的 JIT 编译和解释（以及AOT-编译）实现。

R5RS 中没有任何内容禁止（或建议）Scheme 的 JIT 实现。

即使是像 C++11 这样的强编译语言，理论上也可以进行 JIT 编译。这通常是不值得的。

顺便说一句，您可以找到 C 的 JIT 实现（例如 tinycc）。您还可以找到 C（或 C++）的解释器。还请查看Cling。

您会发现几个 JIT 库。例如查看libgccjit 和LLVM；它们实际上并没有那么“即时”（但它们看起来确实如此，但确实在内部生成了一些汇编程序文件；本质上，它们是足够快的 AOT 编译器，实际上可以用作 JIT 编译器）。但是asmjit 更像是“JIT”-y。

实际上，计算机速度足够快，您可以将某些东西编译成 C，然后运行 ​​GCC 编译（到一些临时插件中），因此将每个 REPL 交互编译为（dlopen-ed）C 代码。 （FWIW，我在我的旧 MELT 事情中做到了）。

还可以阅读 Self 上的旧 Ungar 博士论文。它执行某种 JIT，在极少数情况下会非常慢（有时需要一整天的 CPU），以至于它可能看起来像是 AOT。

同时查看SBCL。它在每次 REPL 交互时编译为机器码。

另请阅读 J.Pitrat 在他的 CAIA 系统上的博客。

在某些方面，JIT 只是一个流行词。（它可能与进行优化的程度和方式有关，特别是因为它能够进行“运行上下文”相关的优化；但请阅读 @ 987654333@).