JIT编译器及其在c ++前加速.net程序执行的好处

Question

我们知道，.net有CLI和JIT来执行程序。但是与在一个阶段中编译所有代码的c ++相比，这两个阶段可能会导致速度和性能降低。我想知道.net的语言如何克服这个缺点并处理它？

Answer 1

在这两个C ++编译器上工作过，现在已经花了几年时间研究.Net JIT，我认为有一些值得考虑的事情：

• 正如许多其他人所指出的那样，JIT正在与您的应用程序一起运行，它试图仔细平衡快速JIT时间与jitted代码的质量。在C ++中看到的更精细的优化通常带有非常高的编译时价格标签，并且在编译时与代码质量图中存在一些非常尖锐的关键。
• 看似可以预先改变这个等式，因为jit预先运行并且可能需要更多时间，但是预测扩大优化范围的能力是非常有限的（例如我们尝试避免引入脆弱的跨程序集依赖性，因此例如不会内联跨越装配边界）。因此预先编写的代码往往比jitted代码运行得慢一些，主要是帮助应用程序启动时间。
• 由于动态类加载，反射以及分析器在正在运行的进程中更新方法体的能力，.Net的默认执行模型排除了许多过程间优化。总的来说，我们认为从这些功能中获得的生产力和应用程序架构是值得的。但是对于不需要这些功能的情况，我们正在寻找方法来确保如果您的应用不需要它，您的应用将不会为此付费。
• 例如，我们在CoreRT中进行了一些“纯粹的”AOT工作，但结果反映有限。
• .Net Core 2.1包含了Tiered jitting的预览，这将允许我们减轻jit时间的一些限制 - 我们将能够投入更多的时间来研究我们知道经常执行的方法。所以我希望看到更复杂的优化随着时间的推移被添加到JIT中。
• .Net Core 2.1还包括硬件内在函数的预览，因此您可以充分利用现代硬件上提供的丰富指令集。
• .Net的JIT还没有从配置文件反馈中获得太多好处。这是我们积极致力于改变的事情，虽然这需要时间，并且很可能与分层相关联。
• .Net执行模型从根本上改变了人们需要考虑某些编译器优化的方式。例如，从编译器的角度来看，许多操作 - 包括字段访问等低级操作 - 可以引发语义上有意义的异常（在C ++中，只有调用/抛出会导致异常）。而.Net的GC精确且重新定位，这在其他方面对优化施加了限制。