時間が経つにつれて、現在の仮想マシン技術は、いくつかのケースでは、Javaや.NETおよび他の仮想マシン集約型コンピューティングのパフォーマンスは、さらに優れた個々のケースでC ++と、に似てきた、より成熟になります。本論文では、現象の背後にある理由を探るために、いくつかのテストケースのパフォーマンスを分析します。
2つの簡単なテストケースを見てください。連続運転LEN = 1000000メモリの5000サイクルは、以下に示すように、実行時間を算出します。左TEST1、右側TEST2。
.NET 3.0 Preview6コア試験下同様の手順。
次のようにテスト結果を比較すると、次のとおりです。
私たちは、test1のために、C ++のバージョンがTEST2のため、C＃とC ++バージョンバージョンのパフォーマンスと同等に、あるいはわずかに速く、はるかに高速で、見ることができます。
なぜこのような現象はありますか？以下の特定の分析：
TEST1割り当てサイクルが位置非依存であるため、コンパイラおよび他の並列SIMD演算命令により最適化することができる、等を最適化するためにSIMD並列計算命令を使用することは困難位置依存コンパイラ循環TEST2割り当て。以上の結果、VCコンパイラから推測することができ、3.0 preview6なしtest1の並列最適化をtest1のと並行して、最適化、および.NETのコアされています。
私たちは、この推測を検証します。NETのコア3.0は、手動以下のTEST1並列最適化試験性能をSIMD命令のサポートを提供します。
結果は0.441sのC ++版に近い0.633s、です。2.289s正面に対して3倍以上の速度で最適化。
同じ手順私は、Java 8の試験結果の驚きを使用します。
test1の0.654s、および.NETコアの並列最適化近似を消費し、我々は並列最適化を行ってきた仮想マシンのJVMを見ることができます。test2は1.755s、C ++版と.NETコアバージョンよりも速く、そして巨大なギャップを消費します！
显然，jvm对test2这种情况进行了特殊关照。要理解这一现象，就需要对Java虚拟机的机制有深入了解。HotSpot 虚拟机里内置了两个JIT编译器：Client Compiler和Server Compiler，简称为C1编译器和C2编译器。C1编译器将字节码编译为本地代码，进行简单、 可靠的优化，如有必要将加入性能监控的逻辑。C2编译会启用一些编译耗时较长的优化，甚至进行一些激进优化。
查找文献可知，默认情况下，当方法调用次数+循环回边次数超过10000、计数器是int等几个简单类型、步增是常量时，会触发C2编译优化。test2恰恰满足这三种情况！
下面我们再设计一个实验，将步增改为变量，看看测试结果：
由测试可知，将步增改为变量后，测试结果为6.163秒，和C++及 .net core 测试结果近似。
针对这个测试案例，可以猜测 C2 优化时进行了循环展开。下面，我们在 .net core 下手动展开循环，测试性能，验证我们的猜想：
测试结果为1.983s，近似java8的1.755s。猜想得到验证。
----
总结：随着JVM、.Net等虚拟机技术的发展，语言特性对高性能计算性能影响越来越低，对计算机体系结构、编译原理、虚拟机编译机制的理解，对性能的影响变得更为重要。JVM的自动优化做的非常的强悍，.net core 在这方面还有不小差距，不过 .net core 可以通过手工优化来弥补这一差距。