即时编译与提前编译相比有哪些优势? [英] What are the advantages of just-in-time compilation versus ahead-of-time compilation?

问题描述

我最近一直在思考，在我看来，JIT 编译的大部分优势应该或多或少地归功于中间格式，而 jitting 本身并不是一种生成代码的好方法.

I've been thinking about it lately, and it seems to me that most advantages given to JIT compilation should more or less be attributed to the intermediate format instead, and that jitting in itself is not much of a good way to generate code.

所以这些是我经常听到的主要 pro-JIT 编译论点:

So these are the main pro-JIT compilation arguments I usually hear:

1. 即时编译允许更大的可移植性.这不应该归功于中间格式吗?我的意思是，一旦你在你的机器上安装了虚拟字节码，没有什么能阻止你将它编译成本地字节码.可移植性是分发"阶段的问题，而不是运行"阶段的问题.
2. 好的，那么在运行时生成代码呢?嗯，同样适用.没有什么能阻止您将满足实时需求的实时编译器集成到您的本机程序中.
3. 但运行时无论如何只将其编译为本机代码一次，并将生成的可执行文件存储在硬盘驱动器上某处的某种缓存中.是的，当然.但是它在时间限制下优化了您的程序，并且从那时起并没有使它变得更好.请参阅下一段.

1. Just-in-time compilation allows for greater portability. Isn't that attributable to the intermediate format? I mean, nothing keeps you from compiling your virtual bytecode into native bytecode once you've got it on your machine. Portability is an issue in the 'distribution' phase, not during the 'running' phase.
2. Okay, then what about generating code at runtime? Well, the same applies. Nothing keeps you from integrating a just-in-time compiler for a real just-in-time need into your native program.
3. But the runtime compiles it to native code just once anyways, and stores the resulting executable in some sort of cache somewhere on your hard drive. Yeah, sure. But it's optimized your program under time constraints, and it's not making it better from there on. See the next paragraph.

它不像提前编译也没有优势.即时编译有时间限制:您不能让最终用户在程序启动时一直等待，因此需要在某处进行权衡.大多数时候，他们只是优化较少.我的一个朋友有分析证据表明手动"内联函数和展开循环(在过程中混淆源代码)对他的C#数字运算性能有积极影响程序;在我这边做同样的事情，我的 C 程序完成相同的任务，没有产生任何积极的结果，我相信这是由于我的编译器被允许进行广泛的转换.

It's not like ahead-of-time compilation had no advantages either. Just-in-time compilation has time constraints: you can't keep the end user waiting forever while your program launches, so it has a tradeoff to do somewhere. Most of the time they just optimize less. A friend of mine had profiling evidence that inlining functions and unrolling loops "manually" (obfuscating source code in the process) had a positive impact on performance on his C# number-crunching program; doing the same on my side, with my C program filling the same task, yielded no positive results, and I believe this is due to the extensive transformations my compiler was allowed to make.

然而，我们周围都是乱七八糟的程序.C# 和 Java 无处不在，Python 脚本可以编译成某种字节码，而且我相信一大堆其他编程语言都可以这样做.我失踪一定有充分的理由.那么是什么让即时编译优于提前编译?

And yet we're surrounded by jitted programs. C# and Java are everywhere, Python scripts can compile to some sort of bytecode, and I'm sure a whole bunch of other programming languages do the same. There must be a good reason that I'm missing. So what makes just-in-time compilation so superior to ahead-of-time compilation?

编辑 为了消除一些混淆，也许重要的是要声明我完全支持可执行文件的中间表示.这有很多优点(实际上，即时编译的大多数参数实际上是中间表示的参数).我的问题是如何将它们编译为本机代码.

EDIT To clear some confusion, maybe it would be important to state that I'm all for an intermediate representation of executables. This has a lot of advantages (and really, most arguments for just-in-time compilation are actually arguments for an intermediate representation). My question is about how they should be compiled to native code.

大多数运行时(或与此相关的编译器)更愿意及时或提前编译它们.由于提前编译对我来说似乎是一个更好的选择，因为编译器有更多的时间来执行优化，我想知道为什么 Microsoft、Sun 和所有其他公司都在反其道而行之.我有点怀疑与分析相关的优化，因为我在即时编译程序方面的经验显示基本优化很差.

Most runtimes (or compilers for that matter) will prefer to either compile them just-in-time or ahead-of-time. As ahead-of-time compilation looks like a better alternative to me because the compiler has more time to perform optimizations, I'm wondering why Microsoft, Sun and all the others are going the other way around. I'm kind of dubious about profiling-related optimizations, as my experience with just-in-time compiled programs displayed poor basic optimizations.

我使用 C 代码示例只是因为我需要一个提前编译与即时编译的示例.C 代码没有发送到中间表示的事实与情况无关，因为我只需要证明 ahead-of-time 编译可以产生更好的即时结果.

I used an example with C code only because I needed an example of ahead-of-time compilation versus just-in-time compilation. The fact that C code wasn't emitted to an intermediate representation is irrelevant to the situation, as I just needed to show that ahead-of-time compilation can yield better immediate results.

推荐答案

ngen 工具页面 大吃一惊(或者至少提供了对原生图像与 JIT 编译图像的良好比较).提前编译的可执行文件通常具有以下好处:

The ngen tool page spilled the beans (or at least provided a good comparison of native images versus JIT-compiled images). Executables that are compiled ahead-of-time typically have the following benefits:

1. 原生图像加载速度更快，因为它们没有太多启动活动，并且需要较少的静态内存(JIT 编译器所需的内存)；
2. 本机图像可以共享库代码，而 JIT 编译的图像则不能.

即时编译的可执行文件通常在这些情况下占上风:

Just-in-time compiled executables typically have the upper hand in these cases:

1. 原生图像比对应的字节码大；
2. 无论何时修改原始程序集或其依赖项之一，都必须重新生成本机图像.

每次有一个组件时都需要重新生成提前编译的图像，这是原生图像的巨大缺点.另一方面，JIT 编译的图像不能共享库代码这一事实会导致严重的内存命中.操作系统可以在一个物理位置加载任何本地库，并与想要使用它的每个进程共享它的不可变部分，从而显着节省内存，尤其是对于几乎每个程序都使用的系统框架.(我想这在某种程度上被 JIT 编译的程序只编译它们实际使用的内容所抵消.)

The need to regenerate an image that is ahead-of-time compiled every time one of its components is a huge disadvantage for native images. On the other hand, the fact that JIT-compiled images can't share library code can cause a serious memory hit. The operating system can load any native library at one physical location and share the immutable parts of it with every process that wants to use it, leading to significant memory savings, especially with system frameworks that virtually every program uses. (I imagine that this is somewhat offset by the fact that JIT-compiled programs only compile what they actually use.)

Microsoft 对此事的总体考虑是，大型应用程序通常会从提前编译中受益，而小型应用程序通常不会.

The general consideration of Microsoft on the matter is that large applications typically benefit from being compiled ahead-of-time, while small ones generally don't.

这篇关于即时编译与提前编译相比有哪些优势?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！