Compilation 有没有人研究过JIT编译器的好处？ 请不要把这变成另一场关于JIT是否比静态编译更好或更差的战争。

静态编译与JIT编译之间存在着大量的冲突。就个人而言，我倾向于静态编译，但这才是真正的问题所在。虽然JIT编译从理论角度来看有各种各样的优势，但我还没有看到任何证据表明这些优势是可以实现的——也就是说，据我所知，这些优势仍然只是理论上的。据我所知，没有人做过任何研究来衡量当前的状态，我们所能做的就是使用我们有偏见的猜测，并将我们的战壕挖得更深，还有一堆基准测试，其中一组语言被误用或完全不相关

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

有没有人做过可信的研究来检查JIT编译器的状态 有没有人做过可靠的研究来检查静态编译器的状态 有没有人对JIT编译器状态研究和静态编译器研究的结果进行过可信的比较 最近的研究比任何只有几年历史的研究都更有价值

直接比较可能是不可行的，但只要有两个真实的研究和真实的经验证据就好了；我意识到这可能是不可能实现的，至少在某种程度上，大多数人都会同意这个结果。我知道，我怀疑这是我们已经或将要进行的最接近真实研究的一次。没有语言，但有许多JIT语言实现

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

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

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

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

顺便说一句，您可以找到C的JIT实现，例如tinycc。您还可以找到C或C++的解释器。也要研究一下

您将发现几个JIT库。例如，调查和调查；它们实际上并不是那么及时，但看起来是这样，但确实会在内部生成一些汇编文件；本质上，它们是足够快的AOT编译器，实际上可以用作JIT编译器。但是更准时

事实上，计算机的速度足够快，你可以把一些东西编译成C，运行一个GCC编译成一些临时插件，从而将每个交互编译成DLC代码。FWIW，我是用我的旧东西做的

还可以阅读关于的旧Ungar博士论文。它执行了某种JIT，在某些罕见的情况下，这种JIT速度非常慢，有时需要一整天的CPU，以至于它可能看起来像是AOT

也要研究一下。它在每次REPL交互时编译为机器代码

还可以阅读J.Pitrat关于其系统的博客

---

在某些方面，JIT只是一个时髦词。它可能与执行优化的程度和方式有关，特别是因为它支持执行与上下文相关的优化；但请阅读。

吹毛求疵。我很确定你完全明白我的意思。不，你把一种语言和它的实现搞混了。JIT是一个实现细节。你说的研究XX语言的状态是什么意思？什么州？有什么可学的？你真的能以同样的方式对待所有JIT/编译语言实现吗？@SergioTulentsev No.这就是为什么我怀疑这是不可能的。请注意，你没有确切地定义JIT编译是什么，也没有确切地说出你关心什么样的好处。