.NET 运行时与 Java Hotspot：.NET 落后一代了吗？
根据我在.NET和Java执行环境上收集到的信息，目前的情况如下：
- 现代Java虚拟机能够执行连续的重新编译，与分析相结合可以产生巨大的性能改进。较旧的 JVM 使用 JIT。 本文的更多信息： http://www.ibm.com/developerworks/library/j-jtp12214/ 特别是：Java 理论与实践：动态编译和性能测量
.NET 使用 JIT 或 NGEN 生成本机代码，但是一旦生成本机代码，就不再执行进一步的（运行时）优化。
抛开基准测试不谈，并且无意升级圣战，这是否意味着 Java Hotspot VM 领先 .Net 一代。 Java VM 中使用的这些技术最终会进入 .NET 运行时吗？
According to the information I could gather on .NET and Java execution environment, the current state of affairs is follows:
Modern Java VM are capable of performing continuous recompilation, which combined with profiling can yield great performance improvements. Older JVMs employed JIT.
More information in this article:
http://www.ibm.com/developerworks/library/j-jtp12214/ and especially: Java theory and practice: Dynamic compilation and performance measurement.NET uses JIT or NGEN to generate native code, but once the native code is generated, no further (runtime) optimizations are performed.
Benchmarks aside and with no intention to escalate holy wars, does this mean that Java Hotspot VM is one generation ahead of .Net. Will these technologies employed at Java VM eventually find its way into .NET runtime?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
他们遵循两种不同的策略。我不认为其中一个比另一个更好。
.NET 不解释字节码，因此它必须在执行时对所有内容进行 JIT，因此由于时间限制而无法进行大量优化。如果您需要对代码的某些部分进行大量优化，您始终可以手动 NGEN，或者执行快速但 不安全实现。此外，调用本机代码很容易。 这里的方法似乎是让运行时足够好并手动优化瓶颈。
现代 JVM 通常会解释大部分代码，然后对瓶颈进行优化编译。这通常比直接 JIT 获得更好的结果，但如果您需要更多，Java 中没有
unsafe，并且 调用本机代码不太好。 所以这里的方法是尽可能多地进行自动优化，因为其他选项都不太好。实际上，与 .NET 相比，Java 应用程序在时间上的性能往往稍好，但在空间上的性能较差。
They follow two different strategies. I do not think one is better than the other.
.NET does not interpret bytecode, so it has to JIT everything as is gets executed and therefore cannot optimise heavily due to time constraints. If you need heavy optimizations in some part of the code, you can always NGEN it manually, or do a fast but unsafe implementation. Furthermore, calling native code is easy. The approach here seems to be getting the runtime good enough and manually optimise bottlenecks.
Modern JVMs will usually interpret most of the code, and then do an optimized compilation of the bottlenecks. This usually gets better results than straight JIT'ing, but if you need more, you don't have
unsafein Java, and calling native code is not nice. So the approach here is to do as much automatic optimising as possible, because the other options are not that good.In reality Java applications tend to perform slightly better in time and worse in space when compared to .NET.
我从来没有对两者进行过基准测试来进行比较，而且我更熟悉Sun JVM，我只能笼统地谈论JIT。
优化总是需要权衡，并且并非所有优化始终有效。然而，这里有一些现代 JIT 技术。我认为，如果我们坚持技术性的内容，这可能是一次良好对话的开始：
还有一些有用的功能VM 的良好实现：
基于这些功能以及更多功能，我们可以比较 VM，而不仅仅是“Java”与“. NET”，但是，比如说，Sun 的 JVM 与 IBM 的 JVM 对比 .NET 与 Mono。
例如，Sun 的 JVM 不执行尾部调用优化 IIRC，但 IBM 的 JVM 执行尾部调用优化。
I've never benchmarked the two to compare, and I'm more familiar with the Sun JVM, I can only speak in general terms about JITs.
There are always tradeoffs with optimizations, and not all optimizations work all the time. However, here are some modern JIT techniques. I think this can be the beginning of a good conversation if we stick to the technical stuff:
There's also features that are helpful as far as good implementations of a VM go:
Based on these features and many more, we can compare VMs, and not just "Java" versus ".NET" but, say, Sun's JVM versus IBM's JVM versus .NET versus Mono.
For example, Sun's JVM doesn't do tail-call optimization, IIRC, but IBM's does.
显然有人正在为 转子。我无法访问 IEEE，因此无法阅读摘要。
.NET JIT 编译器的动态重新编译和配置文件引导优化
引自摘要。 ..
Apparently someone was working on something similar for Rotor. I don't have access to IEEE so I can't read the abstract.
Dynamic recompilation and profile-guided optimisations for a .NET JIT compiler
Quote from Summary...
您可能对 SPUR 感兴趣，是一个跟踪 JIT 编译器。重点是 javascript，但它在 CIL 上运行，而不是语言本身。这是一个基于 Bartok 的研究项目，而不是标准的 .NET VM。该论文有一些性能基准测试，显示“它始终比标准 3.5 CLR 的 SPUR-CLR 执行得更快”。然而，还没有任何关于与当前虚拟机相关的未来的公告。跟踪可以跨越方法边界，这不是 HotSpot 所做的事情 AFAIK，提到了 JVM 跟踪 JIT 这里。
我不太愿意说 .NET VM 落后了一代，尤其是在考虑所有子系统（特别是泛型）时。 GC 和 DLR 与 invokedynamic 比较 我不确定，但有很多有关它们的详细信息，请访问 channel9 等位置。
You may be interested in SPUR which is a Tracing JIT compiler. The focus is on javascript but it operates on CIL not the language itself. It is a research project based on Bartok not the standard .NET VM. The paper has some performance benchmarks showing 'it consistently performs faster than SPUR-CLR' which is the standard 3.5 CLR. There haven't been any announcements about it's future relating to the current VM however. Traces can cross method boundaries which is not something HotSpot does AFAIK, JVM tracing JITs are mentioned here.
I'd be hesitant to say the .NET VM is a generation behind especially when considering all the sub-systems, in particular generics. How the GC and DLR vs invokedynamic compare I'm unsure but there are lots of details about them at places like channel9.