多家权威机构、几十篇权威证据证明:Java比C++更快。如果反对,请举反证。
如果我说Java程序的运行速度比C++程序快,你相信吗?
我知道你会说“不可能,C++是编译执行的,而Java是解释执行的……Java不可能比C++快……”
拜托,现在都二十一世纪了,不要拿这种过时的理论来压人,拿出证据来!无论黑猫白猫,逮着老鼠的才是好猫。是骡子是马拉出来遛遛。不要跟我斗嘴皮子,你跟我斗我还不跟你斗呢~~~~~~~
下面举证Java比C++快(资料全部来自网络):
多家权威机构、几十篇权威证据证明:Java比C++更快 (附众多详细图表,以及链接)
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的数据显示:
j2se1.5在各种单项性能上平均比j2se1.4.2高出10%到30%,而在复杂程序的综合性能上则是j2se1.4的三倍左右。
在丹麦Copenhagen大学的一份长达314页的研究报告中,我们看到:
JDK1.0时,java的速度是C++的20到40分之一。而到了jdk1.4时,java的性能则是C++的三分之一到2倍(通常C++是java的1.2倍到1.5倍)。
可惜这分报告没有jdk1.4以后的数据,而后面的报告我们将看到在jdk1.4.2时,java性能全面超过C++。
java在j2se 1.4.2时就已经在性能上全面超过了以c++,以下是几十个权威证据:。。。。
美国国家标准科技研究院
12项测试中,java获胜7项,C获胜5项。
java:C=7:5
========
结论:大多数情况下,java更快
苹果电脑公司的一份报告:在字符串比较上,Java的性能是C的6.4倍:
美国国家标准科技研究院的另一份报告证明:Java的全面战胜同时代的VC和Borland C
Java写的数据库的性能是C++写的数据库性能的近600倍!
BGS Systems 公司的三位作者的共同研究报告:
We set out to determine if Java applications could approach C++ in performance. We were surprised to see that in a simple client/server application Java actually outperformed MFC.
翻译:我们开始测试是否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%的差距输的
而赢了的三项中有两项是以33%以上的差距获胜的
而Java高性能编译器只以2:3的微小差距略负于高性能Fortran(High-Performance Fortran, version 2.2.)
IBM的报告:
Servlet与CGI的性能对比:
结论:Servlet性能大大超过用C写的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
上面有java和C的源代码
Swing GUI图形界面的性能:
在菜单、树形、文本框、table等几项上,jdk1.4.0比jdk1.3.1快40%到90%
Reflection的性能上,jdk1.4.0比jdk1.3.1快20倍!快20倍以上的还包括远程窗口调用
其它各项上,jdk1.4.0几乎都比jdk1.3.1快50%以上,“Java慢”也只是“历史”了
其它各方面的性能提升在此
http://java.sun.com/j2se/1.4/performance.guide.html
SUN的数据说明,JDK1.4.2在各方面的性能是jdk1.4.1的50%到380%
可以看到,几乎每次java的版本提高都带来性能的极大提升。所以如果你在某处看到一个benchmark说C++比java快,那就很可能是用的老版本的java。
但是C++近年似乎没什么速度的提升
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++!
另一份古老的证据证明:
JDK 1.3就已能在某些方面超过同时代的VC 6.0 与Borland C:
来自Dieselpoint公司:
In fact, there’s no truth to the assertion that Java is slow. Java has evolved to be a great solution for developing ultra-fast software applications.
事实上,说“java慢”是错误的。Java已经进化成开发“超级快”的程序的伟大选择!
It shows that it’s possible to write Java code that outperforms code written in other programming languages, such as C++, if you know what you are doing.
这证明了完全可以用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),它们有不同的优化方针和策略,具体如何,你可以看看Sun的技术文档。