JIT 编译器与离线编译器 [英] JIT compiler vs offline compilers

问题描述

是否存在 JIT 编译器比 C++ 等其他编译器更快的场景?

Are there scenarios where JIT compiler is faster than other compilers like C++?

您认为未来 JIT 编译器只会看到一些细微的优化、功能但遵循类似的性能，还是会出现使其无限优于其他编译器的突破?

Do you think in the future JIT compiler will just see minor optimizations, features but follow a similar performance, or will there be breakthroughs that will make it infinitely superior to other compilers?

看起来多核范式有一些希望，但它不是通用魔法.

It looks like the multi core paradigm has some promise but it's not universal magic.

有什么见解吗?

推荐答案

是的，肯定有这样的场景.

Yes, there certainly are such scenarios.

• JIT 编译可以使用运行时分析来优化特定情况，基于对代码当前实际执行的特性的测量，并且可以根据需要重新编译热"代码.这不是理论上的.Java 的 HotSpot 实际上就是这样做的.
• JITter 可以针对正在执行程序的实际硬件上使用的特定 CPU 和内存配置进行优化.例如，许多 .NET 应用程序将以 32 位或 64 位代码运行，具体取决于它们的 JIT 位置.在 64 位硬件上，它们将使用更多的寄存器、内存和更好的指令集.
• 紧密循环内的虚拟方法调用可以根据引用类型的运行时知识替换为静态调用.

我认为未来会有突破.特别是我认为JIT编译和动态类型的结合会得到显着的提升.我们已经在 Chrome 的 V8 和 TraceMonkey 的 JavaScript 领域看到了这一点.我希望在不久的将来看到其他类似规模的改进.这一点很重要，因为即使是所谓的静态类型"语言也往往具有许多动态特性.

I think there will be breakthroughs in the future. In particular, I think that the combination of JIT compilation and dynamic typing will be significantly improved. We are already seeing this in the JavaScript space with Chrome's V8 and TraceMonkey. I expect to see other improvements of similar magnitude in the not-too-distant future. This is important because even so-called "statically typed" languages tend to have a number of dynamic features.

这篇关于JIT 编译器与离线编译器的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！