关于Java的速度

interneting 2004-10-17 12:16:57
可能是认为C++快的人把此辩论给删了(请版主证实一下,如果不是你删的,请恢复此文),不过幸好我有备份
主  题: 关于Java的真相,JAVAer一定要看



又有人在说Java很慢,Java速度已经达到或超过C++了,请大家不要被偏见迷惑。如果再有人对你说同样的事情,请把这些文章给他看

The Java is Faster than C++ and C++ Sucks Unbiased Benchmark
http://kano.net/javabench/
Java与C++性能对比:
http://www.philippsen.com/JGI2001/finalpapers/18500097.pdf

Java pulling ahead? Performance of Java versus C++

http://www.idiom.com/~zilla/Computer/javaCbenchmark.html

http://www.tommti-systems.de/go.html?http://www.tommti-systems.de/main-Dateien/reviews/languages/benchmarks.html

http://mag.vchelp.net/200312/download/wdn200313.pdf
http://www.javaperformancetuning.com/news/qotm028.shtml
http://www.aceshardware.com/Spades/read.php?article_id=154
http://osnews.com/story.php?news_id=5602&page=3
http://cpp.student.utwente.nl/benchmark/
http://www.kano.net/javabench/data


=====================================
另外补充几篇数据和理论文章。



Performance tests show Java as fast as C++
http://www.javaworld.com/javaworld/jw-02-1998/jw-02-jperf_p.html


JIT Optimization techniques :

Dataflow analysis
Elimination of redundant tests
Translation from stack operations into register operations
Code scheduling
Reduction of memory accesses by register allocation
Method inlining
Dead-code elimination
Elimination of common sub-expression
Loop versioning
Versioning of virtual method calls
Constant propagation

http://www.trl.ibm.com/projects/jit/detail_e2.htm

新的JIT理论:

JIT compiler
– Method invocation optimization[OOPSLA00][JVM02]
– Exception optimization[ASPLOS00][OOPSLA01][PACT02]
– Profiling based optimization[JG00][PLDI03][PACT03]
– Float optimization[JVM02][ICS02]
– 64bit architecture optimization[PLDI02]
– Register allocation[PLDI02]
– Data prefetch[PLDI03]
– Instruction Scheduling[CGO03]
– Compiler overview[JG99][IBMSysJournal00][OOPSLA03]
􀂃 Runtime systems
– Fast lock[OOPSLA99][OOPSLA02][ECOOP04]
– Fast interpreter[ASPLOS02]

http://www.is.titech.ac.jp/ppl2004/proceedings/ishizaki_slides.pdf
http://act.it.sohu.com/book/chapter.php?id=51&volume=1&chapter=9
http://act.it.sohu.com/book/serialize.php?id=51
...全文
2447 95 打赏 收藏 转发到动态 举报
写回复
用AI写文章
95 条回复
切换为时间正序
请发表友善的回复…
发表回复
zfbp 2005-01-11
  • 打赏
  • 举报
回复
我想说的是,大家不要再理楼主这样无聊的家伙了,纯粹帮他造势。就好像媒体借助明星绯闻来提升自己知名度一样。楼主这样的思维,完全就是理想化的,根本不考虑实际应用,我看他八成是书呆子!
nuclearfighter 2005-01-10
  • 打赏
  • 举报
回复
楼主,链接是你给我的,我也没有挑,从上往下一个个来。

我不懂Java发展状况,但是我看得懂网页
http://www.philippsen.com/JGI2001/finalpapers/18500097.pdf
如果你认为自己的数据不权威,那么,不要用那些空话来唬人。拿出来分析才是王道。

1:-server不是表示内存无限,而是表示更深入的优化
===========================
我说的是“几乎”无限,辩论之前先学好语文。结合具体的问题,wc问题的几乎无限就是内存不构成速度限制。
============================
Java用另外的选项进行内存调节












2:这其中java用的是JDK1.2和JDK1.3,是非常非常古老的jdk。jdk1.42的速度是jdk1.3的几倍(见美国国家标准科技研究院的数据:http://math.nist.gov/scimark2/run.html。需要装java才能看上面的applet)
===========================
那么,请给出用新jdk和C/C++之间的比较评测报告,我们再来分析。空口说没用。
====================
前面我已经给出了许多










3:这中的对比,大多数情况下java的最好成绩与C++的差距在20%以内
===========================
但是,你好像宣称的是Java比C/C++更快哦。
===========
那个用的是jdk1.2与1.3。jdk1.4.2要比那1.2和1.3快很多














文件I/O是Java完全可移植的部分吗?
===============

不知道是你无知还是我无知了。Java的可移植性指导里面清清楚楚地说明了这是不可以完全移植的,而且也说明了为什么不可以移植。
===================
证据在哪?













不是给双方同样的汽油才叫公平,给“足够”的汽油才叫公平。......给汽车一吨汽油,汽车的速度也无法提高更多
===============
OK,C++的足够,就是512M,当然,我不限制你给Java加更多的油。既然你认为给汽车一吨汽油也没用,那么,给了也无妨,是不是呢?
顺便纠正你的一个观点,“但给飞机更多油,飞机就可以克服更大阻力飞的更快”这是错误的。战斗机在开加力时,时常会扔掉副油箱,正是为了提高速度和机动性。充其量,油多只可能是飞的远一点,而且这也只是可能还不是一定。当年一个"卸掉一些火箭燃料,让火箭飞得更远"的故事你可以利用google去复习一下了。
=================
你有新的权威数据就拿出来。没有空讲“理论”没半点用








某些Qpper们认为:根本就不存在Java,只存在C++,Java只是一个C++的程序。
===============
真正cpper,哦不,Qpper们从来没有否认过Java,但是还知道要把C++/Java各自放在合时的位置上,上述言论不过是你的臆测而已。
===========
你想说明什么?










JIT和HotSpot编译器可以根据程序运行的CPU进行指令集进行优化,C++编译器可以吗?
===============
我无语,C++编译器不能?玩笑开大了吧?
===========
你不要断章取义。说的很清楚:是表示在“运行时”C++编译器不能针对CPU优化。








JIT和HotSpot编译器可以根据程序运行时的profile对本地代码进行inline等优化,C++编译器可以吗?
===============
C++编译器不能inline?C++基于成本的代码优化听说过吗?并行处理优化了解过吗?
=-=========
“运行时”三个字你不认识?








JIT和HotSpot编译器可以根据程序运行时根据程序运行的情况进行更准确的分支预测,C++编译器可以吗?
===============
首先,现在的CPU有分支预测能力,但这是硬件层面的,要想充分利用这一能力,代码就必须要有相当的可预测性,否则,预测失败会带来惩罚。所以,本质上,Java的分支预测是在和CPU的分支预测角力,那么请拿出Java比硬件分支预测更快的证据来。
至于C++,一方面,它是native code,自然可以利用CPU的分支预测能力,其次,C++还有编译期分支选择,这种选择的结果就是运行期避免的分支预测,换句话说分支预测的时间代价是0!
====================
我说的是“运行时”!!!











并且bytecode的代码要比native code精简的多
===============
我想,你应该知道RISC和CISC的区别吧?指令数和执行速度压根就没有本质联系。
并行度的提高可以大幅度改善性能。别说你不懂并行计算,我会鄙视你的。那么,用intel的并行优化再来比比看matrix?要知道,不知是Jdk在升级,你的C++也该升升级了!
==============
“指令密度”这个词你听说过么?再说我这句话放在我的语境中才有意义。
如果是硬件直接支持指令,越精简的指令就越快:java中一个构造方法要一个指令,而C++中要11个指令













而这仅有的5%的“C++编译器产生的本地代码”(比如AWT.dll)在java程序运行时还要被JIT和HotSpot编译器重新编译成新的指令序列(例如:符合SSE2的指令集的指令),
===============
不知道是我孤陋寡闻还是你胡说八道。是不是5%我不知道,native code要动态编译成新的指令序列,我倒!native code本来就是指令序列,还怎么编译?再说了,除了特定领域,速度关SSE2什么事?从一个x86指令序列转换到另一个指令序列,我靠,从此softICE算坨屎!
=================
使用SSE2能比SSE的程序快很多,你不承认?









C++的速度是由C++编译器在程序员开发时编译出来的机器语言的优化程度决定的。
Java的速度是由Java的JIT和HotSpot编译器将java bytecode在运行时“即时”编译成针对本地CPU的优化的本地代码决定的。
===============
你不知道什么叫交叉编译吗?你不知道什么叫为平台优化吗?C/C++这两者都有!顺便说一句,Qpper们都知道,gcc产生的代码差不多是最慢的C++编译器之一,你用来比较性能,我无语。
===================
看来你真的不认识“运行时”三个字









比速度的实际就是在比:看C++编译器和java编译器谁能产生更优化的机器代码。
===============
这句话很对,但是你怎么就糊涂到看不见这些评测,并非是在“C++产生的机器代码”和“C++产生的机器代码”之间较量呢?
==========
说什么呢?








他们只能抱着一个可怜的、没有任何根据“C++比Java快”终其一生
===============
你也可以抱着“Java比C++快”终其一生。我不同意你的观点,但坚决捍卫你的权利!

================
我有数据,你有吗?
wingfiring 2005-01-07
  • 打赏
  • 举报
回复
楼主,链接是你给我的,我也没有挑,从上往下一个个来。

我不懂Java发展状况,但是我看得懂网页
http://www.philippsen.com/JGI2001/finalpapers/18500097.pdf
如果你认为自己的数据不权威,那么,不要用那些空话来唬人。拿出来分析才是王道。

1:-server不是表示内存无限,而是表示更深入的优化
===========================
我说的是“几乎”无限,辩论之前先学好语文。结合具体的问题,wc问题的几乎无限就是内存不构成速度限制。

2:这其中java用的是JDK1.2和JDK1.3,是非常非常古老的jdk。jdk1.42的速度是jdk1.3的几倍(见美国国家标准科技研究院的数据:http://math.nist.gov/scimark2/run.html。需要装java才能看上面的applet)
===========================
那么,请给出用新jdk和C/C++之间的比较评测报告,我们再来分析。空口说没用。

3:这中的对比,大多数情况下java的最好成绩与C++的差距在20%以内
===========================
但是,你好像宣称的是Java比C/C++更快哦。

文件I/O是Java完全可移植的部分吗?
===============

不知道是你无知还是我无知了。Java的可移植性指导里面清清楚楚地说明了这是不可以完全移植的,而且也说明了为什么不可以移植。

不是给双方同样的汽油才叫公平,给“足够”的汽油才叫公平。......给汽车一吨汽油,汽车的速度也无法提高更多
===============
OK,C++的足够,就是512M,当然,我不限制你给Java加更多的油。既然你认为给汽车一吨汽油也没用,那么,给了也无妨,是不是呢?
顺便纠正你的一个观点,“但给飞机更多油,飞机就可以克服更大阻力飞的更快”这是错误的。战斗机在开加力时,时常会扔掉副油箱,正是为了提高速度和机动性。充其量,油多只可能是飞的远一点,而且这也只是可能还不是一定。当年一个"卸掉一些火箭燃料,让火箭飞得更远"的故事你可以利用google去复习一下了。


某些Qpper们认为:根本就不存在Java,只存在C++,Java只是一个C++的程序。
===============
真正cpper,哦不,Qpper们从来没有否认过Java,但是还知道要把C++/Java各自放在合时的位置上,上述言论不过是你的臆测而已。


JIT和HotSpot编译器可以根据程序运行的CPU进行指令集进行优化,C++编译器可以吗?
===============
我无语,C++编译器不能?玩笑开大了吧?

JIT和HotSpot编译器可以根据程序运行时的profile对本地代码进行inline等优化,C++编译器可以吗?
===============
C++编译器不能inline?C++基于成本的代码优化听说过吗?并行处理优化了解过吗?

JIT和HotSpot编译器可以根据程序运行时根据程序运行的情况进行更准确的分支预测,C++编译器可以吗?
===============
首先,现在的CPU有分支预测能力,但这是硬件层面的,要想充分利用这一能力,代码就必须要有相当的可预测性,否则,预测失败会带来惩罚。所以,本质上,Java的分支预测是在和CPU的分支预测角力,那么请拿出Java比硬件分支预测更快的证据来。
至于C++,一方面,它是native code,自然可以利用CPU的分支预测能力,其次,C++还有编译期分支选择,这种选择的结果就是运行期避免的分支预测,换句话说分支预测的时间代价是0!

并且bytecode的代码要比native code精简的多
===============
我想,你应该知道RISC和CISC的区别吧?指令数和执行速度压根就没有本质联系。
并行度的提高可以大幅度改善性能。别说你不懂并行计算,我会鄙视你的。那么,用intel的并行优化再来比比看matrix?要知道,不知是Jdk在升级,你的C++也该升升级了!

而这仅有的5%的“C++编译器产生的本地代码”(比如AWT.dll)在java程序运行时还要被JIT和HotSpot编译器重新编译成新的指令序列(例如:符合SSE2的指令集的指令),
===============
不知道是我孤陋寡闻还是你胡说八道。是不是5%我不知道,native code要动态编译成新的指令序列,我倒!native code本来就是指令序列,还怎么编译?再说了,除了特定领域,速度关SSE2什么事?从一个x86指令序列转换到另一个指令序列,我靠,从此softICE算坨屎!

C++的速度是由C++编译器在程序员开发时编译出来的机器语言的优化程度决定的。
Java的速度是由Java的JIT和HotSpot编译器将java bytecode在运行时“即时”编译成针对本地CPU的优化的本地代码决定的。
===============
你不知道什么叫交叉编译吗?你不知道什么叫为平台优化吗?C/C++这两者都有!顺便说一句,Qpper们都知道,gcc产生的代码差不多是最慢的C++编译器之一,你用来比较性能,我无语。

比速度的实际就是在比:看C++编译器和java编译器谁能产生更优化的机器代码。
===============
这句话很对,但是你怎么就糊涂到看不见这些评测,并非是在“C++产生的机器代码”和“C++产生的机器代码”之间较量呢?

他们只能抱着一个可怜的、没有任何根据“C++比Java快”终其一生
===============
你也可以抱着“Java比C++快”终其一生。我不同意你的观点,但坚决捍卫你的权利!
nuclearfighter 2005-01-06
  • 打赏
  • 举报
回复
语言不是用快来恒量的,
大家都知汇编语言肯定比C++快,
但国内用纯汇编开发软件的公司多吗??
什么语言都不重要,关键是能搞到钱,
我现在用vj++ ,是ms的东西,不过是java的,听说有高人还能将jdk1.4导入到vj++呢,兴奋中。
================
用java能搞到更多的钱。
两个同样运行速度的语言,首选开发效率高的,这是常识
nuclearfighter 2005-01-06
  • 打赏
  • 举报
回复
wingfiring(别逗了)(非典型秃子) ( ) 信誉:100 2005-01-06 19:50:00 得分: 0


再看看http://www.philippsen.com/JGI2001/finalpapers/18500097.pdf的内容
一共8项测试,前面的一大堆我就不看了,直接看图,这是不管平台的比较,我知道这不大公平,只是===========================
1:-server不是表示内存无限,而是表示更深入的优化
2:这其中java用的是JDK1.2和JDK1.3,是非常非常古老的jdk。jdk1.42的速度是jdk1.3的几倍(见美国国家标准科技研究院的数据:http://math.nist.gov/scimark2/run.html。需要装java才能看上面的applet)
3:这中的对比,大多数情况下java的最好成绩与C++的差距在20%以内












文件I/O是Java完全可移植的部分吗?
===============




















OK,我们再回到这两段看似公平的代码上来。这两段代码都把缓冲区的大小设置为4096,看似公平,其实奸诈。Java 的-server选项意味着什么?几乎无限的内存可用!而C++却因为太小的缓冲区,老老实实的一次又一次的调用系统调用,卑鄙!大家都把缓冲区大小调整到512M,再看看结果!
========================
不是给双方同样的汽油才叫公平,给“足够”的汽油才叫公平。java的内存不都是给IO的,有JVM和重新编译bytecode到本地代码的内存空间。-server选项可以通过JIT内联本地方法调用来站产生更长但更快的代码,并不是为IO准备的。
飞机和汽车比速度时难道也要给同样数量的汽油么?给汽车一吨汽油,汽车的速度也无法提高更多。但给飞机更多油,飞机就可以克服更大阻力飞的更快。

所以只要“有足够内存”就是公平的。


















大家都知道,文件I/O本身是OS支持的,C/C++也好,Java也好都是通过相应的库(运行环境)来调用系统调用而已,好坏的差别,只在于库的好坏和对库使用方法是否正确上。
请问:Java的文件I/O是用java语言来实现的吗,C/C++的I/O库可是用C/C++实现的?wc的比较,充其量,只是在比较两者的库。其次,Java的文件I/O库是什么语言写的,还是个值得怀疑的问题呢。
========================
某些Qpper们认为:根本就不存在Java,只存在C++,Java只是一个C++的程序。
但他们却在有意回避一个事实:

用C++编译器编译出来的本地代码才是C++程序
用Fortran编译器编译出来的本地代码才是Fortran程序
用Delphi编译器编译出来的本地代码才是Delphi程序
用C#编译器编译出来的本地代码才是C#程序
用VB.net编译器编译出来的本地代码才是VB.net程序
用Java编译器编译出来的本地代码才是Java程序

如果照某些Qpper的观点,那么世界上只有机器语言一种语言,因为其它语言归根结底都是机器语言程序,岂不荒唐?


而Java的本地代码是用Java的JIT和HotSpot编译器在程序运行时编译出来的,根本不是C++编译器编译出来的,所以java程序根本不是一个C++程序!


JIT和HotSpot编译器可以根据程序运行的CPU进行指令集进行优化,C++编译器可以吗?
JIT和HotSpot编译器可以根据程序运行时的profile对本地代码进行inline等优化,C++编译器可以吗?
JIT和HotSpot编译器可以根据程序运行时根据程序运行的情况进行更准确的分支预测,C++编译器可以吗?


大家可以去jre1.5.0的安装路径中去看看:
其中的jar文件共有50.5M,由于jar文件是压缩文件,并且bytecode的代码要比native code精简的多(前面已经说过了:一个构造方法在bytecode中只要一个指令,构造方法在C++的编译器却要11个指令。Java 一個 method call 只要一個machine code,但用 x86 相對需要 4 個),所以这50.5M的java程序完成的工作大约相当于200M以上的本地代码完成的工作。
而其中的.exe和.dll共有7.7M,本地代码在java运行环境中占的比例连5%都不到。

而这仅有的5%的“C++编译器产生的本地代码”(比如AWT.dll)在java程序运行时还要被JIT和HotSpot编译器重新编译成新的指令序列(例如:符合SSE2的指令集的指令),并根据运行时的profile 来内联到其它java编译器编译出来的native code中成为全新的NativeCode序列

所以C++编译器编译出来java本地库的机器代码序列在java运行的时候根本看不到,这些机器代码也被Java的JIT和HotSpot编译器重新编译并更改执行序列,这些“C++编译器编译出来的机器代码”已经变成了“Java编译器编译出来的机器代码”。最终,在CPU中执行的所有机器语言序列全部是由Java编译器产生的,与C++编译器没有一点关系





C++的速度是由C++编译器在程序员开发时编译出来的机器语言的优化程度决定的。
Java的速度是由Java的JIT和HotSpot编译器将java bytecode在运行时“即时”编译成针对本地CPU的优化的本地代码决定的。

比速度的实际就是在比:看C++编译器和java编译器谁能产生更优化的机器代码。
很明显,C++的编译器不如java的JIT和HotSpot编译器,因为JIT和HotSpot编译器能针对CPU指令集进行人优化、能在运行时根据使用频率对method进行内联和优化。而C++的静态编译器永远也做不到这些

两者有着本质的不同,但是有些Qpper用一辈子也无法理解这其中的差别,
他们只能抱着一个可怜的、没有任何根据“C++比Java快”终其一生
ssDOn 2005-01-06
  • 打赏
  • 举报
回复
语言不是用快来恒量的,
大家都知汇编语言肯定比C++快,
但国内用纯汇编开发软件的公司多吗??
什么语言都不重要,关键是能搞到钱,
我现在用vj++ ,是ms的东西,不过是java的,听说有高人还能将jdk1.4导入到vj++呢,兴奋中。
nuclearfighter 2005-01-06
  • 打赏
  • 举报
回复
我们看到对于足够大的数据数组中,Java RMI性能优于HPC++、Nexus RMI/HPC++和Nexus RMI。。。。。
更惊人的是:在使用JIT后,Java RMI性能优于HPC++

We see that Java RMI outperforms HPC++, Nexus RMI/HPC++, and Nexus RMI
for suciently large data arrays. Since data is pipelined in Java RMI, but not in Nexus RMI, this result
is reasonable. What is more surprising is that when the JIT is enabled, Java RMI is able to outperform
HPC++.

作者:
Fabian Breg, Shridhar Diwan, Juan Villacis,
Jayashree Balasubramanian, Esra Akman, Dennis Gannon

Indiana大学计算机科学系
Department of Computer Science
Indiana University
http://www.cs.ucsb.edu/conferences/java98/papers/rmi.pdf











另一个证据:

题目:
DEVELOPMENT OF A JAVA-BASED METEOROLOGICAL WORKSTATION BY GERMAN
METEOROLOGICAL SERVICE AND PARTNERS
德国气象服务与伙伴用Java开发气象工作站



German Weather Service DWD and German
Military Geophysical Service decided two years ago
to develop a new meteorological workstation from
scratch
德国气象服务局(DWD)与德国军事地球物理服务局决定开发一套全新的气象工作站
.....

The performance issue was evaluated before in a pilot project and is
analysed during all phases of development. It
turned out that this is not a problem, however many
things must be considered in the design and during
coding. Even numerical calculatuions are now in
pure Java since we found they can outperform C++
when carefully optimized.
性能问题在一个导航项目开发之前进行了评估。结果是:性能不是问题,但在编码过程中要考虑很多事情。
我们发现:在优化过后,纯Java甚至连数学计算的性能也超过了C++
http://ams.confex.com/ams/pdfpapers/52402.pdf














再一个证据:
题目:<<Is Java ready for computational science?>>
<<Java为科学计算做好准备了吗?>>

出处:Computer Science Dept., University of Karlsruhe, Germany
德国Karlsruhe大学计算机科学系
http://www.ubka.uni-karlsruhe.de/vvv/1998/informatik/27/27.pdf.gz


IBM的Java编译器以3:2战胜Fortran 90
Fortran90:Java的结果(单位为秒)
20:14
40:30
440:444
1080:1089
11790:11690
输了的两项是以不到!%的差距输的
而赢了的三项中有两项是以33%以上的差距获胜的


文章中的结论:

Conclusion:
Java will become a major language for computational science.
Java将成为科学计算中的主要语言











还有一个证据:
<<Real Java for Real Time>>
用在实时领域中的真正的java


The best JIT compilers today
generate code that come close to, or in some cases even
outperform, C++ code.
当今最好的JIT编译器可以产生性能接近甚至超过C++的代码

http://www.lucas.lth.se/publications/pub2002/nilsson_realjavaforrealtime.pdf


三位作者:
Anders Nilsson、Torbjorn Ekman、Klas Nilsson

瑞典Lund大学计算机科学系
Dept. of Computer Science
Lund University
SWEDEN










One More证据:
<<Java server benchmarks>>
其中对比了Servlet与C/C++写的CGI的各方面的性能

结论:
Conclusion:
Java servlets outperform CGI
Java Servlet的性能超过CGI
http://www.research.ibm.com/journal/sj/391/baylor.html








Servlet与CGI的性能对比:
结论:Servlet性能大大超过用C写的CGI:

基准所取得的结果是:
管理 — 为 64 个节点 SP 配置开发和成功地实现了 Java 和 WebSphere 安装和有效的管理过程。
稳定性 — 大规模 WebSphere 配置的稳定性通过烤机测试证明,在这种测试中,64 个节点的 WebSphere 系统,连续 48 小时运行,硬件或软件没有故障或错误。收集的连续 12 小时以上的性能数据表明稳定的吞吐量和 CPU 利用率。
可扩展性 — 在多达 64 个节点的配置中,在低量和高量工作负载的情况下,通过显示几乎线性的吞吐量(页面浏览量/秒/节点数)证明可扩展性。
性能 — Java 和 WebSphere 技术可以 300% 完成规定的目标。当前的 C/CGI 技术,在 CPU 利用率为 37% 时,大约提供 1.3 次页面浏览/秒/节点;CPU 利用率为 30-40% 时,IBM 的 Java 和 WebSphere 技术大约提供 3.8 次页面浏览/秒/节点。CPU 利用率更高时(> 90%),使用 64 个节点的配置能够在平均响应时间小于 2 秒的情况下提供 564 次页面浏览/秒/节点。假设是类似 2000 年 2 月 Schwab 所安装的配置,这种级别的性将能在“市场风暴”(在此期间有大量的请求)中支持 100,000 次并发的最终用户会话。

图表见原原文:
http://www-900.ibm.com/developerWorks/cn/wsdd/hvws/Schwab2001.shtml







评测报告:.NET的性能仍然远远落后于Java

.NET上同样代码的运行速度并不随运行次数的增加而提高,说明.NET CLR只是简单地进行了JIT编译。而在Hotspot Server上,不仅开始时的性能就有优势,而且速度还会不断提高

可以看到,随着运行次数的增加,Sun Hotspot Server不断将领先优势拉大,最后几乎比.NET 1.1快了一倍。.NET CLR始终无法将运行时间降低到8秒以下,而Sun Hotspot Server在多次运行之后则可以保持在5秒以下。因此,Cameron认为,对于大运算量的应用程序,Hotspot JVM比Microsoft CLR要快得多。
http://www.5d.cn/bbs/archivecontent.asp?id=792254










结论:Java与Fortran一样快
Java Pro 2002-2003中文精华合集[第1辑]
《Java够快吗》
http://act.it.sohu.com/book/chapter.php?id=51&volume=1&chapter=9
http://act.it.sohu.com/book/serialize.php?id=51
参考文献
J.E. Moreira, et. al.,"The Ninja Project,"
Communications of the ACM, 44(10), 102, (2001).
<<ACM通讯>>
Z. Budimli, K. Kennedy, and J. Piper,
"The Cost of Being Object-Oriented: A Preliminary Study,"
<<科学计算>>
Scientific Computing, 7(2), 87, 1999.

Zoran Budimli网站的: www.cs.rice.edu/~zoran










这是SUN对比J2EE与.net的Benchmark报告:
J2EE是.net速度的200%
Web Services Performance
http://java.sun.com/performance/reference/whitepapers/WS_Test-1_0.pdf




可能第三方的结论会更客观:



2004年11月4日最新数据!!!!!!
http://www.shudo.net/jit/perf/
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
FFT , SOR,Monte Carlo, Sparse matmult,LU 这5个Benchmark的结果:
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
C#.net根本不值一提,0:5 输给java。
在综合比分上,java VS C#=324:240
java大比分领先
至于mono就差的更远了
java以324:163完胜mono







再来个证据:

Java is quite efficient nowadays, and it is often reported that it can outperform C++ under some circumstances because it can perform run-time optimizations

Java目前效率很高,经常有报告说Java性能高于C++,因为Java能进行运行时的优化
http://www-pw.physics.uiowa.edu/das2/das_qa.html















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
nuclearfighter 2005-01-06
  • 打赏
  • 举报
回复
http://www.ukhec.ac.uk/events/javahec/pozo.pdf
作者:美国国家标准科技研究院
java:C=7:5
==============
结论:大多数情况下,java更快








http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
作者:美国南加州大学计算机图形与Immersive技术实验室J.P.Lewis and Ulrich Neumann:
Java领先
=========
结论:大多数测试中java获胜










http://www.shudo.net/jit/perf/
FFT , SOR,Monte Carlo, Sparse matmult,LU 这5个Benchmark的结果:
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Java/Sun JDK 1.4.2 Server VM = VS C/VC++ =2:3
VC 获胜
综合比分324:329=98.5% java性能是C++的98.5
在此,C++用SSE2编译。
由于在客户端VC++(windows)不能用SSE2编译,所有的java平台上只要打开-server选项就可以以此速度运行。
===========================
结论:在大多数的客户端程序上,C++程序跑不过java


java速度是GCC的122%

Java/Sun JDK 1.4.2 Server VM VS C/gcc (-O2) =3:2
java 获胜
综合比分=324:266=122%
Java性能是C/GCC的122%
所以在linux上,java更快
===================
结论:在非windows上的大多数情况下,java更快


















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)
=====================
结论:综合来说,java更快











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://www.tommti-systems.de/go.html?http://www.tommti-systems.de/main-Dateien/reviews/languages/benchmarks.html

以下由于第3个表格中java打开了优化选项,所以只有第三个项目中代表了java的真正速度
java:C++=9:5大比分


其中前两个表格中都用了java 1.5 alpha测试版,并且前两表格没打开-server参数。所以我们只看第三个表格(打开了-server优化参数)中的结果:

各种语言在各个方面中夺取的第一名:

java 1.4.2_03(得到9项第一):
double math
trig Math
IO
exception
hashmap
hashmaps
list
nested loop
string concat

C++ (MS 或 Intel,。得到5项第一。 MS compiler options: /Op /Oy /O2 /Oi /Og /Ot /EHsc /arch:SSE
# Intel(R) compiler options: /Op /Oy /Qpc80 /fast /G6 /Oi /Og /Ot /EHsc /arch:SSE)
int32 math
long 64 math
array
heapsort
matrix multiply

值得一提的是:
以上测试中,java在exception上的处理速度竟是C++的约18倍
====================
结论:java在打开-server选项后,取得了大多数测试的冠军






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-i686
=================
结论:基本战平
但是在此测试中,作者说他“故意”限制了JVM的内存使用量,说这是为了和C++公平。这其实是很不公平的。
java打开-server的目的就是为了“用空间换时间”,在内存中将bytecode编译成更大但是更快的本地码,作者却限制内存使用,
就如同飞机与汽车比速度时给飞机和汽车同样数量的汽油一样,或者在限制飞机的飞行高度为5米以下一样(飞机在燃料不足或低空的情况下是不可能以最快的速度飞行了)
看似公平,实则极不公平,飞机就是靠大量的燃料来加速,不给燃料还比什么呢?
如果不限制内存使用量的话,相信java会更快








再来一个证据:


IBM’s research JVM (参考[38] )has demonstrated that Java can
outperform C and FORTRAN compilers even for numerical calculations.

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

(参考[38]:作者:S. M. José Moreira, Manish Gupta,
论文: "A Comparison of Three Approaches to
Language, Compiler, and Library Support for Multidimensional Arrays in
Java,"

presented at Joint ACM Java Grande - ISCOPE 2001 Conference,
Stanford University, 2001.

2001年ISCOPE大会,2001年在斯坦福大学召开 )

iwillsw 2005-01-06
  • 打赏
  • 举报
回复
以现在的CPU速度和内存容量,为争速度千方百计优化没有多少意义
wingfiring 2005-01-06
  • 打赏
  • 举报
回复
再看看http://www.philippsen.com/JGI2001/finalpapers/18500097.pdf的内容
一共8项测试,前面的一大堆我就不看了,直接看图,这是不管平台的比较,我知道这不大公平,只是看一看最强者:
冠军 垫底
图1,pgcc3.2.3 (c/C++) sun jdk 1.30 server
图2,IBM Jdk1.30 (Java), sun jdk 1.30 client
图3,compaq fortran v5.3-1120(for) 第二名是dec c 同上
4, dec c v5.9-005(c/c++) Java 1.30 alpha1
5 同上 sun jdk 1.30 client
6 同上 Latte0.9.1(不知道什么系统)
7 同上 Java 1.30 alpha1
8 同上 IBM Jdk1.30
另外,图和表格中的内容不完全一致,这使得我很怀疑这份结果的权威性,就这样粗制滥造的东西也敢自夸权威?大概Javer和Cpper的评判标准实在是天壤之别吧。

再看表格的数据,这个比较公平:
NT下,唯有Series一项,IBM JDK夺冠。
linux下,HeapSort、Series两项IBM JDK 1.30夺冠。
sun ultraSparc, Java全面告北,
Compaq Es40, Java全面告北,

我就奇了怪了,楼主是贴错了链接还是脑子有问题?这不是在帮我们这些cpper,哦不,是Qpper吗?
本来还打算继续往下看链接的,现在,我要考虑考虑楼主是否来自另一个星球,理解问题的逻辑莫非和我们不大一样?

这个世界有两样东西是无限的,一是宇宙,另一个则是人的愚蠢。宇宙的无限我辈是无从领略了,人的愚蠢还真是随处可见啊。
wingfiring 2005-01-06
  • 打赏
  • 举报
回复
好,我没那么多时间吵C++好还是Java好,所以,我就先瞻仰一下楼主给出的链接吧,
第一个:
http://kano.net/javabench/
里面有两段代码
http://kano.net/javabench/src/cpp/
http://kano.net/javabench/src/java/
代码我不贴了,自己看去,是一段统计单词数(wc)的代码.
嘿嘿,我不知道写着代码的人是不是像楼主说的那样是“真正的高手”,好在当年学习unix的时候,也恰好读过一点讨论wc性能的文章,结论是:这位“高手”不是糊涂蛋就是骗子。
了解过wc的人都知道,wc的快慢,取决于两个方面:I/O速度和字符串扫描。现在的计算机速度足够快了,在字符串扫描方面速度提高很快,那么重点就比文件I/O了。那么,我要请问一句:文件I/O是Java完全可移植的部分吗?
大家都知道,文件I/O本身是OS支持的,C/C++也好,Java也好都是通过相应的库(运行环境)来调用系统调用而已,好坏的差别,只在于库的好坏和对库使用方法是否正确上。
请问:Java的文件I/O是用java语言来实现的吗,C/C++的I/O库可是用C/C++实现的?wc的比较,充其量,只是在比较两者的库。其次,Java的文件I/O库是什么语言写的,还是个值得怀疑的问题呢。

OK,我们再回到这两段看似公平的代码上来。这两段代码都把缓冲区的大小设置为4096,看似公平,其实奸诈。Java 的-server选项意味着什么?几乎无限的内存可用!而C++却因为太小的缓冲区,老老实实的一次又一次的调用系统调用,卑鄙!大家都把缓冲区大小调整到512M,再看看结果!

楼主也许是不屑或者说不敢分析代码的,那么我就先抛个砖头。谁快谁不快?我想,楼主要比较的还是两者的程序吧?比代码,那是比什么狗屁文章图表更直接。

kile 2005-01-05
  • 打赏
  • 举报
回复
重复的争论持续了好几年了,,,,感觉没开始那么有意思也没那种斗志了,,,用了几年这两种东西,,,什么需求用什么才是应该。我相信JAVA的速度在不断提高,但是跟C++比较速度,也得在充分保证配置的情况之下吧,不过这么说也有点无奈。感觉很无聊,至于楼上说.net,,,,我觉得.net做为一个framework跟sunone拼是市场行为,,,,.net和C++本身不是同种概念。。咋理解地?
mrwest 2005-01-05
  • 打赏
  • 举报
回复
C++的老鸟也不用天天咬着C++不肯放手,未来不是C++的天下,如果C++真的什么都应付得来,微软干吗还要做.NET?????用什么语言都要看看市场的需求,如果市场不再需求了,那么这种语言也就没用了,C++恐怕离这一天越来越近了,JAVA之所以慢,是因为他又跨平台的特性,如果你不想利用这种特性,你完全可以提升速度。C++的老鸟没必要继续顽固下去了,C++的时代过去了。
nuclearfighter 2005-01-04
  • 打赏
  • 举报
回复
全部几十个java比C++快的证据在此:
http://community.csdn.net/Expert/TopicView.asp?id=3678896


全部有关java、C++性能和前景的东西:
http://community.csdn.net/Expert/TopicView3.asp?id=3636713 (贴子很长,可能要几分钟才能全部打开)
ilovevc 2005-01-04
  • 打赏
  • 举报
回复
吹吧。举几个特别的例子在特定的情况下证明java比C/C++快并不是什么难事。
愤怒的不争 2005-01-04
  • 打赏
  • 举报
回复
我觉得我们不应该讨论这写东西.

c++和java有各自适合的场合和环境。
nuclearfighter 2005-01-04
  • 打赏
  • 举报
回复
当然好的剑还要有好身手才行。

现在大家已经知道Java是把锋利的剑(比C++和自称Sharp的C#还要锋利),剩下的事就是大家自己好好练用Java的武功了
nuclearfighter 2005-01-04
  • 打赏
  • 举报
回复
其实何必争这个,你写的程序都要给用户用的,他们说快就快,说慢就慢,你们说些编译器类库优化什么的他们懂吗?还不是双击一下,感觉上慢了就不爽
================
Word、Outlook启动也很慢。windows media player甚至连打开个长一点儿的播放列表都要半天。难道感觉能说明问题?
再说“感觉慢”就一定是java本身的问题?也许是程序员写的有问题。

所以现在要做的首先是消除程序员和用户的“Java慢的”偏见。

如果以后再有人攻击java慢,javaer就有武器撼卫真理了,javaer也不用被迫去用很复杂的方法(如很复杂的算法或JNI或C++)去提升性能了。
fdm_sea 2005-01-04
  • 打赏
  • 举报
回复
其实何必争这个,你写的程序都要给用户用的,他们说快就快,说慢就慢,你们说些编译器类库优化什么的他们懂吗?还不是双击一下,感觉上慢了就不爽
nuclearfighter 2005-01-04
  • 打赏
  • 举报
回复
回复人: wingfiring(别逗了)(非典型秃子) ( ) 信誉:100 2004-12-3 9:57:54 得分: 0


Java VM core
这个不和你比性能。你Java VM干嘛要用C++写啊?你VM越快,不就是C++越快?

============================
C++的速度是由C++编译器在程序员开发时编译出来的机器语言的优化程度决定的。
Java的速度是由Java的JIT和HotSpot编译器将java bytecode在运行时“即时”编译成针对本地CPU的优化的本地代码决定的。

比速度的实际就是在比:看C++编译器和java编译器谁能产生更优化的机器代码。
很明显,C++的编译器不如java的JIT和HotSpot编译器,因为JIT和HotSpot编译器能针对CPU指令集进行人优化、能在运行时根据使用频率对method进行内联和优化。而C++的静态编译器永远也做不到这些

两者有着本质的不同,但是有些Qpper用一辈子也无法理解这其中的差别,
他们只能抱着一个可怜的、没有任何根据“C++比Java快”终其一生














某些Qpper们认为:根本就不存在Java,只存在C++,Java只是一个C++的程序。
但他们却在有意回避一个事实:

用C++编译器编译出来的本地代码才是C++程序
用Fortran编译器编译出来的本地代码才是Fortran程序
用Delphi编译器编译出来的本地代码才是Delphi程序
用C#编译器编译出来的本地代码才是C#程序
用VB.net编译器编译出来的本地代码才是VB.net程序
用Java编译器编译出来的本地代码才是Java程序

如果照某些Qpper的观点,那么世界上只有机器语言一种语言,因为其它语言归根结底都是机器语言程序,岂不荒唐?


而Java的本地代码是用Java的JIT和HotSpot编译器在程序运行时编译出来的,根本不是C++编译器编译出来的,所以java程序根本不是一个C++程序!


JIT和HotSpot编译器可以根据程序运行的CPU进行指令集进行优化,C++编译器可以吗?
JIT和HotSpot编译器可以根据程序运行时的profile对本地代码进行inline等优化,C++编译器可以吗?
JIT和HotSpot编译器可以根据程序运行时根据程序运行的情况进行更准确的分支预测,C++编译器可以吗?




Qpper们,上台继续表演“阿Q精神胜利法”吧!

加载更多回复(75)

62,612

社区成员

发帖
与我相关
我的任务
社区描述
Java 2 Standard Edition
社区管理员
  • Java SE
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧