问题标签 [jit]

Sun 的规范 JVM 实现对字节码进行了一些非常复杂的优化，以便在代码运行几次后获得接近本机的执行速度。

问题是，为什么不将此编译后的代码缓存到磁盘以供后续使用同一函数/类时使用？

就目前而言，每次执行程序时，JIT 编译器都会重新启动，而不是使用代码的预编译版本。当字节码本质上被解释时，添加这个特性不会显着增加程序的初始运行时间吗？

正如我们都知道和喜爱的那样，IntegerOverflow每次整数溢出时，.NET 都会引发异常。我认为这是一件非常好的事情。

但我想知道他们是如何做到这么快的。x86 不会捕获整数溢出，如果其他架构允许这样做，我会感到惊讶。我为 x86 找到的最佳解决方案是在每个算术运算之后放置一条“INTO”指令。但我认为这会导致明显的放缓。

他们可以在编译器中进行一些静态检查，以避免在可以证明操作不会溢出的情况下发生这种情况。但是当编译器无法确定操作的结果时，性能关键的内部循环会怎样呢？

我试图查看 Mono 源代码，但找不到他们进行这些检查的位置。

那么有人知道他们真正在做什么吗？我真的很想知道。

附带说明：有没有办法查看 .NET JITC 发出的 x86 代码？

I've read that there is a jit compiler module for dalvik vm on the works and the results are quite promising. Some people claim an improvement of 100% in terms of execution speed. Does anyone have an idea when it is going to be incorporated in an android release? The amount of RAM on the nexus one (512MB) hints that a jit may be introduced soon. Android 2.5 maybe?

到目前为止，大多数主流浏览器已经开始将优化 JIT 编译器集成到他们的 JavaScript 解释器/虚拟机中。这对每个人都有好处。现在，我很难确切知道它们执行了哪些优化以及如何最好地利用它们。每个主要 JavaScript 引擎的优化参考有哪些？

背景：

我正在开发一个编译器，它可以从更高级和更安全的语言生成 JavaScript（无耻的插件：它被称为OPA，它非常酷），并且考虑到我正在生成的应用程序的大小，我希望我的 JavaScript 代码能够尽可能快并尽可能节省内存。我可以处理高级优化，但我需要更多地了解执行了哪些运行时转换，以便了解哪些低级代码会产生最佳结果。

一个例子，我想到的：我正在编译的语言将很快集成对惰性的支持。JIT 引擎在惰性函数定义中表现良好吗？

以下代码在 Visual Studio 中运行版本和在 Visual Studio 之外运行版本时给出不同的输出。我正在使用 Visual Studio 2008 并以 .NET 3.5 为目标。我也尝试过 .NET 3.5 SP1。

在 Visual Studio 外部运行时，JIT 应该启动。要么（a）我缺少的 C# 发生了一些微妙的事情，要么（b）JIT 实际上是错误的。我怀疑 JIT 是否会出错，但我已经没有其他可能性了......

在 Visual Studio 中运行时的输出：

在 Visual Studio 之外运行发布时的输出：

是什么原因？

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

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

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

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

然而，我们被jittered 的程序所包围。C#和Java无处不在，Python 脚本可以编译成某种字节码，我敢肯定一大堆其他编程语言也能做到这一点。我失踪一定有充分的理由。那么，是什么让即时编译优于提前编译呢？

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

大多数运行时（或就此而言的编译器）将更喜欢即时编译或提前编译它们。由于提前编译对我来说似乎是一个更好的选择，因为编译器有更多的时间来执行优化，我想知道为什么 Microsoft、Sun 和所有其他公司都在反其道而行之。我对与性能分析相关的优化有点怀疑，因为我对即时编译程序的经验表明基本优化很差。

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

我有一个每天运行的 JAVA 进程，需要大约 1,000 或 2,000 次点击才能完全被 JIT 优化。我想做的是保存 JIT 信息，以便第二天它可以在优化状态下启动。看起来这应该是可能的，但我还没有找到任何方法来做到这一点。

Q1) 为什么 C# 最初编译为 IL，然后在运行时 JIT 编译并在虚拟机上运行（？）。还是 JIT 符合本机机器代码？

Q2）如果第二个为真（JIT 符合本机机器代码），那么代码运行的 .NET 沙箱在哪里？

Q3）另外，为什么首先将代码编译为IL。为什么不一直简单地编译为本机代码呢？MS 有一个名为 ngen 的工具，但为什么它是可选的？

我最近了解了需要在应用程序开始服务实际请求之前预热应用程序（具有高吞吐量要求）的场景。这背后的逻辑是让 JIT 发挥其性能魔力！

这是 Java 应用程序的规范，还是通常用于内存重（占用空间）应用程序？

我一直在查看 mscorlib 以查看通用集合如何优化其枚举器，我偶然发现了这一点：

堆栈大小为 3，字节码大小应为 80 字节。该MoveNextRare方法的命名让我大吃一惊，它包含一个错误案例和一个空集合案例，因此显然这违反了关注点分离。

我假设该MoveNext方法以这种方式拆分以优化堆栈空间并帮助 JIT，我想对我的一些性能瓶颈做同样的事情，但是没有硬数据，我不希望我的巫毒编程变成货物-邪教；）

谢谢！弗洛里安