有没有像“编译时 JIT”这样的东西？答案

【问题标题】：Is there something like "compile-time JIT"?有没有像“编译时 JIT”这样的东西？
【发布时间】：2014-07-12 04:20:24
【问题描述】：

据我了解，JIT（即时编译）是指run-time 过程，其中字节码被编译（翻译）为本机代码以提高运行时性能。

另一方面，编译时评估是通用编程或运行时优化的常见做法。同样，据我了解，在这种情况下，编译器解释源代码以评估表达式（产生例如值或类型）。在这种情况下，编译时间通常会显着增加。

是否有一个编译时 JIT 过程，其中编译器将源代码转换为本机代码以实现更有效的编译时评估？我觉得这很自然，但是任何编译器都可以用任何语言做到这一点吗？

如果我要在自己的编译器中执行此操作，会不会是个好主意？与运行时 JIT 相比，我会遇到哪些额外困难？

【问题讨论】：

您的意思是提前将字节码编译为原生？如果是这样，互联网上有很多程序可以做到这一点。因为“编译时 JIT”没有意义。 “编译时间”是“在用户运行它之前”。并且“JIT”是“作为/在用户开始运行它之后”。真的不可能有混血儿。在用户启动代码之前或之后/之后进行编译。
哦等等，你的意思是编译器在哪里生成本地代码，然后在静态编译期间执行本地代码？我希望 C++ constexpr 完全适用于这个概念，尽管我怀疑 C++ 中的其他任何东西。 C++ 中常量和类型的编译时评估通常不是执行“代码”，而是“在表中查找内容”。（我显然会 C++，不会说其他语言）
@MooingDuck 是的，我的意思是你在第二条评论中所说的。 C++ constexpr 在编译时进行所有评估，但我不知道如何。我读到 D 通过解释代码来做到这一点，这比运行本机代码慢 1-2 个数量级。只是测量编译时间（clang 或特别是 gcc），我不认为 C++ 在实践中做得更好。

【解决方案1】：

没有任何意义。编译器已经在编译代码。常量表达式求值只发生一次。以 Java HotSpot JVM 为例，只有在方法被执行数千次后才发现将其编译为本机代码是有益的。

【讨论】：

常量表达式求值只发生一次源代码的每次更改。也就是说，根据您要编写的代码，它很可能每分钟发生一次，持续 30 秒。
C++允许你编写编译器在编译过程中执行的函数，我想这就是他所指的，如果那些被解释或编译然后执行。
就此而言，像lex 和yacc 这样的工具可以预先计算输入语法的标记化和解析表，可以被认为是一种预先计算的形式。 在一般情况下对程序员透明需要部分评估。

【解决方案2】：

我认为您所说的——在默认行为是解释或即时代码生成时提前执行代码生成——被称为 ahead-of-time (AOT) compilation。

好处：

缺点：

您可以想象对 AOT 编译的代码进行配置文件导向的整个程序优化，但最终您会得到类似于 HotSpot 运行时的“预热”版本的东西，在足够热的方法上交换共享内存以值得修改他们的翻译。

【讨论】：

Jeffrey Hantin，你能说出一些 AOT，比如最新 4.4 Android 中的 ART runtime，Java 中的 Excelsior JET 和 GCJ？..
@osgx，我在 CLR 领域待了这么久，以至于想到了 Mono AOT 和 Microsoft NGen。
感谢您的指点，但这不是我的意思。我的意思是，编译器看到一个可以在编译时计算的表达式，比如fibonacci(15)；它编译fibonacci，为其生成native code；它调用这个函数并计算结果；它将结果作为常量插入，替换表达式；它正常编译其余代码，生成本机代码或中间代码或其他代码；在运行时，这个表达式根本不需要计算。我希望这更清楚。
@iavr 哦！介于constant folding 和partial evaluation 之间。常量折叠只是一种可能属于部分评估范围的优化。
@JeffreyHantin 没错，对不起，我认为compile-time evaluation 也很清楚。无论如何，我知道这至少在 C++ (constexpr) 和D 中经常发生，它只是让编译变得如此缓慢，因此我的问题。