首先:我必须承让,我取JAVA比C++更快?为标题是有点故意吸引眼球的意思.
事实上在本文中,我的主要目的不是为了证明或否定JAVA比C++更快这一个结论(事实上标题中的"?"已经隐含了这一点),而是通过引用几位JAVA大牛的文章深入JIT与Hotspot的实现原理,来说明为什么JAVA可以比C++更快.当然,在你有你自己的结论之前,我希望你能仔细看一下文中引用的几篇文章,而不是想当然.
注意:文中大部分内容或结论是引用别人的文章,有一些是我自己的看法,文中用绿色标出.
1.静态编译与Hotspot动态编译
我们知道,C++相对Basic等解释型语言,之所以性能上有明显的优势,主要是因为C++在运行的时候已经通过编译器编译为二进制的机器语言,并且现代的编译器可以在编译的时候做大量的最优化处理;而Basic等解释型语言运行的时候是通过解释器一步步的解释运行,这样中间隔了一个解释器,速度当然就慢了.
而JAVA刚出世的时候采取的也是解释执行的方法(现在某些低端设备上的JRE还是解释执行),只不过它比Basic更聪明一点:不是直接解释JAVA源代码,而是先将JAVA源代码编译为一种平台无关的JAVA字节码.这样执行速度可能会比Basic快一些,但相对C++的执行效率还是有很大的差别.
然后,JIT(just-in-time)编译器出现了.JIT编译器在每段代码执行前进行编译，编译的结果为本地静态机器码，执行速度有了质的提高.到这儿,我们可以比较一下C++的静态编译与JRE的JIT静态编译:一个是在运行前将代码编译为机器语言,一个是在运行时将字节码编译为机器语言,相比而言,JAVA的JIT编译器还是显得笨一点,预先一次编译比运行时再编译当然要好了.但对于JAVA,为了跨平台,这样做是必须的.
JIT静态编译器相对解释执行已经有了很大的提高,但是性能仍然和C++有很大的差距.对一段程序,一名优秀的程序员是如何来改进运行速度的呢?首先,他不会傻到把所有的代码都来优化,他会观察、思考到底哪段代码对整体性能影响最大?然后集中精力来优化这一段代码.按照经验,整个程序 10%-20%的代码,会占据 80%-90%的运行时间.用这种方法，在同样的时间、付出同样程度的努力后,这名优秀的程序员使整个程序的性能得到了很大程度的优化.HotSpot引擎,就是模仿人工的这种方法进行优化的.在程序运行的开始,Java代码仍然解释执行,但HotSpot引擎开始进行采样(Profiling).根据采样的结果,决定某段程序是占用较多运行时间的,就认为它是“HotSpot”,它也就是目前程序的瓶颈,引擎开始启动一个单独的线程进行优化.因为不象原始的 JIT编译器那样无差别的编译所有代码,HotSpot引擎可以集中精力来对HotSpot代码进行深度优化,这样这部分代码执行起来更加迅捷.
2.让我们来看看JIT/Hotspot的工作
一般来说,JVM或JAVA的标准API没有提供让我们观察Hotspot工作(产生机器码)的接口.所以以前我们只能猜测Hotspot在背后究竟做了那些事情,我们写的JAVA代码被它弄成什么样子了.
不过现在好了,Java SE Update N这一系列因为处于开发状态,为了方便debug,这些JVM提供了一个运行参数:PrintOptoAssembly,你可以通过如下方式:
3.JVM的执行效率可以比C++更高?
事实上,我认为现在将JAVA与C++比较执行效率没什么太多的意义了.我的意思是,JAVA已经足够快了.而且说实话,经过学C++再学JAVA之后,我已经对C++这门语言避而远之了.
不过为了满足一下某些人的八卦精神,我这里给出几个JAVA与C++的比较:
The Java is Faster than C++ and C++ Sucks Unbiased Benchmark
FreeTTS - A Performance Case Study
Performance comparison C++, C# and Java
八卦之后,我们来看看为什么JAVA能过这么快呢?
同样,给出几篇介绍JIT/Hotspot工作原理的文章:
JIT Performance: Defying Physics?
Can JIT'ed Code be Faster than Hardware Accelleration
事实上在本文中,我的主要目的不是为了证明或否定JAVA比C++更快这一个结论(事实上标题中的"?"已经隐含了这一点),而是通过引用几位JAVA大牛的文章深入JIT与Hotspot的实现原理,来说明为什么JAVA可以比C++更快.当然,在你有你自己的结论之前,我希望你能仔细看一下文中引用的几篇文章,而不是想当然.
注意:文中大部分内容或结论是引用别人的文章,有一些是我自己的看法,文中用绿色标出.
1.静态编译与Hotspot动态编译
我们知道,C++相对Basic等解释型语言,之所以性能上有明显的优势,主要是因为C++在运行的时候已经通过编译器编译为二进制的机器语言,并且现代的编译器可以在编译的时候做大量的最优化处理;而Basic等解释型语言运行的时候是通过解释器一步步的解释运行,这样中间隔了一个解释器,速度当然就慢了.
而JAVA刚出世的时候采取的也是解释执行的方法(现在某些低端设备上的JRE还是解释执行),只不过它比Basic更聪明一点:不是直接解释JAVA源代码,而是先将JAVA源代码编译为一种平台无关的JAVA字节码.这样执行速度可能会比Basic快一些,但相对C++的执行效率还是有很大的差别.
然后,JIT(just-in-time)编译器出现了.JIT编译器在每段代码执行前进行编译，编译的结果为本地静态机器码，执行速度有了质的提高.到这儿,我们可以比较一下C++的静态编译与JRE的JIT静态编译:一个是在运行前将代码编译为机器语言,一个是在运行时将字节码编译为机器语言,相比而言,JAVA的JIT编译器还是显得笨一点,预先一次编译比运行时再编译当然要好了.但对于JAVA,为了跨平台,这样做是必须的.
JIT静态编译器相对解释执行已经有了很大的提高,但是性能仍然和C++有很大的差距.对一段程序,一名优秀的程序员是如何来改进运行速度的呢?首先,他不会傻到把所有的代码都来优化,他会观察、思考到底哪段代码对整体性能影响最大?然后集中精力来优化这一段代码.按照经验,整个程序 10%-20%的代码,会占据 80%-90%的运行时间.用这种方法，在同样的时间、付出同样程度的努力后,这名优秀的程序员使整个程序的性能得到了很大程度的优化.HotSpot引擎,就是模仿人工的这种方法进行优化的.在程序运行的开始,Java代码仍然解释执行,但HotSpot引擎开始进行采样(Profiling).根据采样的结果,决定某段程序是占用较多运行时间的,就认为它是“HotSpot”,它也就是目前程序的瓶颈,引擎开始启动一个单独的线程进行优化.因为不象原始的 JIT编译器那样无差别的编译所有代码,HotSpot引擎可以集中精力来对HotSpot代码进行深度优化,这样这部分代码执行起来更加迅捷.
2.让我们来看看JIT/Hotspot的工作
一般来说,JVM或JAVA的标准API没有提供让我们观察Hotspot工作(产生机器码)的接口.所以以前我们只能猜测Hotspot在背后究竟做了那些事情,我们写的JAVA代码被它弄成什么样子了.
不过现在好了,Java SE Update N这一系列因为处于开发状态,为了方便debug,这些JVM提供了一个运行参数:PrintOptoAssembly,你可以通过如下方式:
3.JVM的执行效率可以比C++更高?
事实上,我认为现在将JAVA与C++比较执行效率没什么太多的意义了.我的意思是,JAVA已经足够快了.而且说实话,经过学C++再学JAVA之后,我已经对C++这门语言避而远之了.
不过为了满足一下某些人的八卦精神,我这里给出几个JAVA与C++的比较:
The Java is Faster than C++ and C++ Sucks Unbiased Benchmark
FreeTTS - A Performance Case Study
Performance comparison C++, C# and Java
八卦之后,我们来看看为什么JAVA能过这么快呢?
同样,给出几篇介绍JIT/Hotspot工作原理的文章:
JIT Performance: Defying Physics?
Can JIT'ed Code be Faster than Hardware Accelleration
引用
java -XX:+PrintOptoAssembly -server -cp . Main
运行你的程序,就可以看到这些JAVA程序在编译为机器语言之后的样子.
Kohsuke Kawaguchi做了一些测试,他在博客深入JAVA生成的机器码(Deep dive into assembly code from Java)中进行了一些展示与讲解.并且他对JVM生成的优化代码表示赞赏:
引用
All in all, modern JVMs seem pretty good at generating optimal code. In various situations, the resulting assembly code is far from the straight-forward instruction-by-instruction translation.
引用
◇ Really aggressive inlining
◇ Even storage allocation & initialization gets inlined - new T() really is as efficient as C's alloca() (and it beats the pants off malloc())
◇ Careful management of cache prefetching
◇ Deep understanding of variablity between the flavors of x86 machines
◇ Loop unrolling with warmup/cooldown
◇ "theorum proving away" of array index checks (and many other things)
◇ much cleverness with locks
