随着时间的发展，现在的虚拟机技术越来越成熟了，在有些情况下，Java，.Net等虚拟机密集计算的性能已经和C++相仿，在个别情况下，甚至还要更加优秀。本文详细分析几个性能测试案例，探讨现象背后的原因。
来看两个简单的测试用例。如下图所示，均是循环5000次，操作 len = 1000000 的连续内存，计算执行时间。左侧为test1，右侧为test2。
类似的程序在 .net core 3.0 Preview6下测试。
测试结果对比如下：
我们可以看见，对于test1，C++版本要快很多，对于test2，C#版本和C++版本性能相当，甚至略快。
为什么会出现这种现象呢？下面来具体分析：
test1 的循环的赋值是位置无关的，因此，编译器可以通过SIMD等并行计算指令来优化，test2 的循环的赋值是位置相关的，编译器很难使用SIMD等并行计算指令来优化。通过上面的结果可以猜测，VC编译器，对test1进行了并行优化，而.net core 3.0 preview6 没有对test1 进行并行优化。
我们来验证这一猜测。.net core 3.0 提供了对SIMD 指令的支持，下面手动对test1进行并行优化，测试性能：
结果是0.633s，接近于C++版本的0.441s。相对于优化前的2.289s，提速了3倍多。
同样的程序，我用 java 8 测试，结果大吃一惊：
test1 耗时 0.654s，和并行优化后的.net core近似，可见 jvm 虚拟机对此进行了并行优化。test2 耗时1.755s，比C++版本和.net core版本都要快，并且差距巨大！
显然，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 可以通过手工优化来弥补这一差距。