Java VS C/C++ 运行速度的对比

1.1 Java VS C/C++

Java与C++相比的优点在于：

u  Java比C,C++简单，学起来比C\C++容易

u  Java完全对象化，比如数组在Java中是一个对象，含有length这个属性；而不像C++中数组是一个指针。所以访问数组，Java都会进行边界检查，更安全，但牺牲了速度。同时因为Java中所有类都会继承Object基类，所以可以把几个好不相干的类用基类联系起来，比如放在同一个数组里。

u  Java中没有指针的概念。

u  Java中有完善的内存管理机制，能自动垃圾回收，最大可能降低内存溢出的可能，同时提高编程效率。

u  Java中有完善的异常机制（标准C++中不够完善）。

u  java中保持数据时对象本身是在堆里，同时靠一在栈里的句柄与之连接。这个设计更合理。

u  Java标准库完整的多，相比之下C++除了一个STL（而且还超级难用）就没了，实际C++编程中需要大量使用第3方库。这很大程度上是因为Java有一些商业公司支持，更新速度快，而C++只有一个可怜的标准委员会，上一个C++标准版本还是C++98。

u  Java因为是把程序编译为字节码，运行时需要JVM把字节码再翻译为机器码，所以他跨平台，一次编译到处运行。但这也是他慢的根本原因。

u  Java原生支持多线程（C++仅靠标准库办不到），原生的UI,如AWT Swing。

   

C++与Java相比的优点在于：

l  Java比C\C++慢。Java 1.0 比C慢20倍 现在的Java 1.6运行速度也只是C的一半。

l  C++在继承和派生上比Java更灵活。

l   C++ 中可以直接插入汇编 能直接操控底层硬件 所以操作系统还是得用c写。

l  Java办的到C++一定办得到，C++办得到的Java则不一定。

l  Sun被甲骨文收购了之后，Java的发展很受影响。

l  C++编译的程序可以直接运行，Java需要安装JRE有几十MB,影响产品发布的用户体验。

 

1.2 常规思维：C/C++比Java快

常规认为：java运行速度比C++慢。主要原因是：

l  java是解释性语言，java程序在运行时类加载器从类路经中加载相关的类，然后java虚拟机读取该类文件的字节，执行相应操作。而C++编译的时候将程序编译成本地机器码。一般来说java程序执行速度要比C++慢10-30倍。即使采用just-in-time compiling （读取类文件字节后，编译成本地机器码）技术，速度也要比C++慢好多。

l  java程序有要从网络上加载类字节，然后执行，这也是导致java运行速度慢的原因。

l  在程序运行过程中，java虚拟机要检测数组是否越界，在C++中则不检测。

l  java中所有的对象都创建在堆中，没有对象被创建在stack中，而C++有的对象和变量是创建在stack中的

l  java在运行过程中检测对象的引用是否为空，如果引用指向都空指针，且执行某个方法时会抛出空指针异常

l  java运行时对类型检测，如果类型不正确会抛出ClassCastException异常。

l  java的垃圾回收机制较C++由程序员管理内存效率更低。

l  java中的原始数据类型在每个操作系统平台长度都是相同，而C++这些数据类型长度是随操作系统的不同而不同，所以java在不同操作系统上执行时有个转化过程。

l  在java中String 是UNICODE.当java要操作一个 ASCII string 时，比C++效率上相对要低一些。

l  java中采用的是动态链接。

 

可以看出，这些比较，全部停留在理论的角度。那么实际应用如何呢？是骡子是马，需要拉出来溜溜嘛！

1.3 实际权威测试结果

http://nuclearjava.blogchina.com/642833.html

Java比C++快的理论依据

http://nuclearjava.blogchina.com/1792677.html

驳“.net比java快”的谎言

http://nuclearjava.blogchina.com/1902610.html

 

摘要

C++的速度是由C++编译器在程序员开发时编译出来的机器语言的优化程度决定的。

Java的速度是由Java的JIT和HotSpot编译器将java bytecode在运行时“即时”编译成针对本地CPU的优化的本地代码决定的。

比速度的实际就是在比：看C++编译器和java编译器谁能产生更优化的机器代码。

很明显，C++的编译器不如java的JIT和HotSpot编译器，因为JIT和HotSpot编译器能针对CPU指令集进行人优化、能在运行时根据使用频率对method进行内联和优化。而C++的静态编译器永远也做不到这些。

据IBM研究院的数据显示，随着java技术的进步，java在同样的硬件上的性能从1996年到2001年提高了10倍，而且还在不断提高。

SUN的数据显示：j2se 1.5在各种单项性能上平均比j2se 1.4.2高出10%到30%，而在复杂程序的综合性能上则是j2se1.4的三倍左右。

在丹麦Copenhagen大学的一份长达314页的研究报告中，我们看到：

JDK 1.0时，java的速度是C++的20到40分之一。而到了jdk1.4时，java的性能则是C++的三分之一到2倍（通常C++是java的1.2倍到1.5倍）。在jdk 1.4.2时，java性能全面超过C++。

java在j2se 1.4.2时就已经在性能上全面超过了以c++，以下是几十个权威证据。

美国国家标准科技研究院 12项测试中，java获胜７项,C获胜5项。结论：大多数情况下，java更快；

苹果电脑公司的一份报告：在字符串比较上，Java的性能是C的6.4倍：

美国国家标准科技研究院的另一份报告证明：Java的全面战胜同时代的VC和Borland C；

Java写的数据库的性能是C++写的数据库性能的近600倍！

BGS Systems 公司的三位作者的共同研究报告：我们开始测试是否java程序能够接近C++的性能。但我们吃惊的发现：在client/server应用程序中，java性能优于MFC。

伯克利大学和Lawrence伯克利国家实验室的一份报告证明：IBM的JDK比GCC更快：

用纯java写的JDK底层要比用C++写JDK底层要快：

JNode是一个纯java的操作系统，其jdk底层是用纯java写的。

美国国家标准研究院的一分报告：Java战胜MS VC++ Netbot 联合公司的证据：http://www.javaworld.com/javaworld/jw-02-1998/jw-02-jperf_p.html

中： java和C++在以下方面打成平手

Integer division

Dead code

Dead code with Integer division

Floating-point division

Static method

Member method

Virtual member method

但java在以下方面的速度是C++的约3倍

Virtual member method with down cast and Run-Time Type Identification (RTTI)

http://www.kano.net/javabench/data

14项Benchmark中，Java获胜9项，C＋＋5项 。java以9：5战胜C++，而且其中很多项是以大比分领先：

Methord Call:近20倍

Object creation：4倍

Hash: 2倍半

word count:1倍半

Fibonacci：1倍半

http://cpp.student.utwente.nl/benchmark/

结果：

14个Benchmark中

Java-server SUN JDK1.4.2以6比8负于Inter C++8.0

Java-server SUN JDK1.4.2以8比6战胜GCC-i686

Java-server SUN JDK1.4.2以7比7战平GCC-i386

结论：基本战平

但是在此测试中，作者说他“故意”限制了JVM的内存使用量，说这是为了和C++公平。这其实是很不公平的。

java打开-server的目的就是为了“用空间换时间”，在内存中将bytecode编译成更大但是更快的本地码，作者却限制内存使用，

就如同飞机与汽车比速度时给飞机和汽车同样数量的汽油一样，或者在限制飞机的飞行高度为5米以下一样(飞机在燃料不足或低空的情况下是不可能以最快的速度飞行了)

看似公平，实则极不公平，飞机就是靠大量的燃料来加速，不给燃料还比什么呢？如果给飞机和汽车同样多的燃料，飞机每跑100米就要停下来加一次油，怎么可能发挥最快速度呢？

而且,所有的java程序都会比相同算法的c++程序的内存用的多，毕竟JVM就要占去很多内存，如果想比较java和c++的速度，就绝不能要求他们的内存是相同的，就如同想比较飞机和汽车谁快，就绝不能要求他们用的油是相同的。

如果不限制内存使用量的话，相信java会更快。

IBM研究的JVM已经证明了Java即使在数学运算中性能也超过C和Fortran。

Fortran90:Java的结果（单位为秒）

20:14

40:30

440:444

1080:1089

11790:11690

输了的两项是以不到1％的差距输的

而赢了的三项中有两项是以３３％以上的差距获胜的

而Java高性能编译器只以2：3的微小差距略负于高性能Fortran（High-Performance Fortran, version 2.2.）

 

IBM的报告：Servlet与CGI的性能对比： 结论：Servlet性能大大超过用Ｃ写的CGI：评测报告：.NET的性能仍然远远落后于Java

麻省理工大学的一位研究员的报告：再来看看用纯java写的MD5算法FastMD5，使用JIT进行native编译后的FastMD5，在linux上处理679,477,248 bytes 大的文件，Java Fast MD5的成绩是34.325秒，而用C写的RedHat linux的textutils-2.0.14-2.i386.rpm用时是59.87667秒。而且，java经过一些设置后，速度还能比前面的更快。英文原文见：http://www.twmacinta.com/myjava/fast_md5.php

 

Swing GUI图形界面的性能： 在菜单、树形、文本框、table等几项上，jdk1.4.0比jdk1.3.1快４０％到９０％。Reflection的性能上，jdk1.4.0比jdk1.3.1快２０倍！快２０倍以上的还包括远程窗口调用 。其它各项上，jdk1.4.0几乎都比jdk1.3.1快５０％以上，“Java慢”也只是“历史”了 。其它各方面的性能提升在此

http://java.sun.com/j2se/1.4/performance.guide.html

 

ＳＵＮ的数据说明，JDK1.4.2在各方面的性能是jdk1.4.1的５０％到３８０％ 可以看到，几乎每次java的版本提高都带来性能的极大提升。所以如果你在某处看到一个benchmark说Ｃ＋＋比java快，那就很可能是用的老版本的java。 但是Ｃ＋＋近年似乎没什么速度的提升

http://java.sun.com/j2se/1.4.2/1.4.2_whitepaper.html

 

英国爱丁堡并行计算中心（http://www.ukhec.ac.uk/publications/reports/hpc_java_comp.pdf），由于使用了古老的JDK1.3.1，而且没有打开-server选项运行java，所以不能代表java最高速度。尽管如此，还是能够看到Java的性能非常接近C和Fortran：

在1000000次方法调用(method call)的测试中，Java 1.0的性能竟是C++的171.2%！也就是说：Java在1.0版本时就在"方法调用"这一项上超过了C++！

 

 

Dieselpoint公司：JDK 1.3就已能在某些方面超过同时代的VC 6.0 与Borland C：事实上，说“java慢”是错误的。Java已经进化成开发“超级快”的程序的伟大选择！这证明了完全可以用java写出比其它语言(例如c++)更快的程序http://dieselpoint.com/pdf/WhitePaper-JavaAndPerformance.pdf

JIT编译器知道什么处理器正在运行，可以产生对应此处理器的优化代码。它知道是否处理器是P3或P4，是否SSE2存在，cache有多大。一个C++之类的预先编译器只能针对所有处理器的指令集的“最小公分母”进行编译，至少在商业软件中是这样的。因为JIT编译器知道哪些类被实际装载和调用，它知道哪些方法可以被“消虚拟化(de-virtualized)” 和内联(值得一提的是：当代java编译器还能知道在被覆盖的方法被装载的情况下，在JIT编译后进行“逆编译”内联的方法调用)。

 

Java code比C++更快的原因：C++进行的优化是静态优化，都是在编译的时候进行的。一旦编译链接生成的可执行本地代码，就盖棺定论了， 不能更改了，除非是Hacker或是病毒。就现在的编译技术来看，静态优化在总体上还是最成熟的，并且在编译的时候它没有时间压力，可以花很长时间来优化程序。这点Java和.NET是不允许的。但是静态优化也有它的缺点，因为它不知道这些程序在运行的时候具体会有什么特征，无法针对性地进行优化。比如它就不可能“大胆”的进行Method inlining。因为它胆子大了就可能犯错误。比如一个Class A,它有个简单函数public int Foo() {return 3;},它的两个子类B和C Override了这个Foo()函数。那么在静态编译的时候，C++的编译器不能将Foo()这个函数作inlining优化，因为它不知道在运行的时候到底是A,还是B或是C的Foo()被调用。而Java的虚拟机在运行时就会知道这些信息。如果发现运行的时候是B的Foo()在反复被调用，那么它就 大胆的将B的Foo()拿到调用者的程序里面来，这样的inlining处理避免了Function call的开销（仔细说就是No method call；No dynamic dispatch；Possible to constant-fold the value）。对于简单的小函数，调用开销往往比执行还费时间。省略了这些开销性能会成倍的提高。如果这些小函数被上千上万次的调用，那么这样优化下来的效果就非常明显了。这也就是Java在有的时候比C++更快的原因之一。当然，Java做优化实际上相当复杂，因为“大胆”优化有时候也会出现问题。比如 将B的Foo()的inlining了，结果突然的蹦出一个对A的Foo()的调用，那程序岂不是要出问题？这个时候呢，Java要退一步，进行反优化 （De-optimization），以确保程序的正确。就这样，Java的虚拟机“骑着毛驴看账本---走着瞧”。一边执行，一边优化，运行不停，优化不止。从外表上看，Java的程序执行会不停的有小的波 动。我说的动态优化/反优化就是原因之一（还有很多其他原因）。Java这种特性非常适合长时间运行的服务器端程序，因为这样Hotspot才有足够的机会对程序进行优化。如果程序只是简单的“Hello world”，那Hotspot一点忙帮不上。并且对于“Hello world”这么个简单的程序，一个Java VM也要启动，这就像你点着了一台锅炉，只是想煎一个鸡蛋。好多人觉得Java慢，最初的影像可能就是来源于此。

 

有人这时候一定会问：“既然这样，那为什么Hotspot不对程序就行全盘优化，那样岂不是更好？”。问题是这样的，优化是有代价的。比如一段程序运行要 2毫秒，优化要10毫秒。如果这段程序的执行密度很低，那么Hotspot就会觉得优化不划算而不予优化。你不妨这样想，Hotspot是一个精明的商人，赔本的生意它绝对不会做。

 

最后再指出一点，那就是Hotspot有客户机和服务器两套(-client, -server)，它们有不同的优化方针和策略。