http://www.idiom.com/~zilla/Computer/javaCbench.html 作者：美国南加州大学计算机图形与Immersive技术实验室J.P.Lewis and Ulrich Neumann： Java领先 ========= 结论：大多数测试中java获胜
http://www.shudo.net/jit/perf/ FFT ， SOR，Monte Carlo， Sparse matmult，LU 这5个Bench的结果： %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 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://cpp.student.utwente.nl/bench/ 结果： 14个Bench中 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大会，２００１年在斯坦福大学召开 ）
我们看到对于足够大的数据数组中，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甚至连数学计算的性能也超过了Ｃ＋＋ 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编译器以３：２战胜Fortran 90 Fortran90:Java的结果（单位为秒） 20:14 40:30 440:444 1080:1089 11790:11690 输了的两项是以不到！％的差距输的 而赢了的三项中有两项是以３３％以上的差距获胜的 文章中的结论： 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. 当今最好的ＪＩＴ编译器可以产生性能接近甚至超过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 benchs＞＞ 其中对比了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性能大大超过用Ｃ写的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 这是ＳＵＮ对比J2EE与.net的Bench报告： 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个Bench的结果： ＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆ 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快４０％到９０％ 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的版本提高都带来性能的极大提升。所以如果你在某处看到一个bench说Ｃ＋＋比java快，那就很可能是用的老版本的java。 但是Ｃ＋＋近年似乎没什么速度的提升 http://java.sun.com/j2se/1.4.2/1.4.2_whitepaper.html
以上是＜＜事实证明：Java比C++快＞＞中的证据集合 http://community.csdn.net/Expert/TopicView3.asp?id=3636713 请认为本贴有价值的人将本贴存在自己的电脑中（用ＩＥ可能无法直接存储，请用FireFox存储，或全选本文再存成txt文件） C++的速度是由C++编译器在程序员开发时编译出来的机器语言的优化程度决定的。 Java的速度是由Java的JIT和HotSpot编译器将java bytecode在运行时“即时”编译成针对本地CPU的优化的本地代码决定的。 比速度的实际就是在比：看C++编译器和java编译器谁能产生更优化的机器代码。 很明显，C++的编译器不如java的JIT和HotSpot编译器，因为JIT和HotSpot编译器能针对CPU指令集进行人优化、能在运行时根据使用频率对method进行内联和优化。而C++的静态编译器永远也做不到这些 两者有着本质的不同，但是有些Qpper用一辈子也无法理解这其中的差别， 他们只能抱着一个可怜的、没有任何根据“C++比Java快”终其一生 以下是Java比Ｃ＋＋快的理论依据： 关于java如此快的原因： 有些东西确实只有JIT能做到： 比如中提到： http://www.idiom.com/~zilla/Computer/javaCbench.html The compiler knows what processor it is running on, and can generate code specifically for that processor。 JIT编译器知道什么处理器正在运行，可以产生对应此处理器的优化代码。在这一点上，C++的静态编译器肯定做不到。 # The compiler knows what processor it is running on, and can generate code specifically for that processor. It knows whether (for example) the processor is a PIII or P4, if SSE2 is present, and how big the caches are. A pre-compiler on the other hand has to target the least-common-denominator processor, at least in the case of commercial software. JIT编译器知道什么处理器正在运行，可以产生对应此处理器的优化代码。它知道是否处理器是P3或P4，是否SSE2存在，cache有多大。一个C++之类的预先编译器只能针对所有处理器的指令集的“最小公分母”进行编译，至少在商业软件中是这样的。 # Because the compiler knows which classes are actually loaded and being called, it knows which methods can be de-virtualized and inlined. (Reably, modern java compilers also know how to "uncompile" inlined calls in the case where an overriding method is loaded after the JIT compilation happens.) 因为JIT编译器知道哪些类被实际装载和调用，它知道哪些方法可以被“消虚拟化(de-virtualized)” 和内联(值得一提的是：当代java编译器还能知道在被覆盖的方法被装载的情况下，在JIT编译后进行“逆编译”内联的方法调用) # A dynamic compiler may also get the branch prediction hints right more often than a static compiler. 动态编译器可以进行更多的分支预测 重点强调： ＊＊＊ Java速度如此快的原因在此（来源：IBM东京研究院） http://www.is.titech.ac.jp/ppl2004/proceedings/ishizaki_slides.pdf ＊＊＊ 其中有6大步优化， 每个大步中又有若干小步的优化， 共几十步的优化。 自己看吧，英语比较简单，只是内函比较难理解， 如果自己看不明白，别人解释也一样听不懂。
对，新版的J2SE 1.6改名字叫Java SE 6，官方名称不再叫J2SE 1.x.x等，都改为Java SE X 另外以后更新版本也没有所谓的1.x.x版本了，改成Java SE 6 update release x了。 Java 5就是Java SE 5，也就是JDK 1.5.x。Java以前的名字可真乱。 从版本1.5开始，Sun Java的平台都叫Java SE X，更新版叫Java SE X update release x了。 另外企业版改名叫Java EE X了，宏版叫Java ME X。
我把 http://math.nist.gov/sci 的java和c代码下载下来测试了一下， java 和 c 的版本每个测了3次，以下是输出结果 (数值的单位是 Mflops. (Million Floationg Point/Second，每秒百万个浮点操作)，这个值越高越好) 最后的结果是5项测试里面只有一项java比C快C:\Documents and Settings\Administrator\桌面\sci2_1c>java -cp sci2lib.jar jnt.sci2.commandlineSciMark 2.0aComposite Score: 174.0996577855954 FFT (1024): 130.40076160821025 SOR (100x100): 235.33889206168786 Monte Carlo : 33.554432 Sparse matmult (N=1000, nz=5000): 171.92025020190837 LU (100x100): 299.28395305617056java.vendor: Sun Microsystems Inc. java.version: 1.6.0 os.arch: x86 os.name: Windows 2000 os.version: 5.0C:\Documents and Settings\Administrator\桌面\sci2_1c>java -cp sci2lib.jar jnt.sci2.commandlineSciMark 2.0aComposite Score: 174.63467967379245 FFT (1024): 129.81844721921811 SOR (100x100): 235.33891947212564 Monte Carlo : 33.288126448727645 Sparse matmult (N=1000, nz=5000): 173.32980063389954 LU (100x100): 301.3981045949912java.vendor: Sun Microsystems Inc. java.version: 1.6.0 os.arch: x86 os.name: Windows 2000 os.version: 5.0C:\Documents and Settings\Administrator\桌面\sci2_1c>java -cp sci2lib.jar jnt.sci2.commandlineSciMark 2.0aComposite Score: 175.01133040295787 FFT (1024): 129.81844721921811 SOR (100x100): 233.51369872149715 Monte Carlo : 33.554432 Sparse matmult (N=1000, nz=5000): 174.76266666666666 LU (100x100): 303.4074074074074java.vendor: Sun Microsystems Inc. java.version: 1.6.0 os.arch: x86 os.name: Windows 2000 os.version: 5.0--------------------------------------------------------------------- 以下是C的结果 C:\Documents and Settings\Administrator\桌面\sci2_1c\test\Release>test ** ** ** SciMark2 Numeric Bench, see http://math.nist.gov/sci ** ** for details. (Results can be submitted to [email protected]) ** ** ** Using 2.00 seconds min time per kenel. Composite Score: 275.65 FFT Mflops: 140.98 (N=1024) SOR Mflops: 185.78 (100 x 100) MonteCarlo: Mflops: 43.61 Sparse matmult Mflops: 458.45 (N=1000, nz=5000) LU Mflops: 549.43 (M=100, N=100) C:\Documents and Settings\Administrator\桌面\sci2_1c\test\Release>test ** ** ** SciMark2 Numeric Bench, see http://math.nist.gov/sci ** ** for details. (Results can be submitted to [email protected]) ** ** ** Using 2.00 seconds min time per kenel. Composite Score: 275.68 FFT Mflops: 140.98 (N=1024) SOR Mflops: 185.71 (100 x 100) MonteCarlo: Mflops: 43.61 Sparse matmult Mflops: 458.45 (N=1000, nz=5000) LU Mflops: 549.65 (M=100, N=100) C:\Documents and Settings\Administrator\桌面\sci2_1c\test\Release>test ** ** ** SciMark2 Numeric Bench, see http://math.nist.gov/sci ** ** for details. (Results can be submitted to [email protected]) ** ** ** Using 2.00 seconds min time per kenel. Composite Score: 275.83 FFT Mflops: 141.67 (N=1024) SOR Mflops: 185.78 (100 x 100) MonteCarlo: Mflops: 43.59 Sparse matmult Mflops: 458.45 (N=1000, nz=5000) LU Mflops: 549.65 (M=100, N=100)
我把-server加上了，但是刚才的C程序是用VC6缺省参数编译的，所以为了公平，这次换成了VC2005 Express版本的缺省参数编译，现在的结果是:C:\Documents and Settings\Administrator\桌面\sci2_1c>java -cp sci2lib.jar -server jnt.sci2.commandlineSciMark 2.0aComposite Score: 307.588970666762 FFT (1024): 150.8336752366756 SOR (100x100): 387.8733963674583 Monte Carlo : 88.12720146546992 Sparse matmult (N=1000, nz=5000): 263.7263439793699 LU (100x100): 647.3842362848362java.vendor: Sun Microsystems Inc. java.version: 1.6.0 os.arch: x86 os.name: Windows 2000 os.version: 5.0C:\Documents and Settings\Administrator\桌面\sci2_1c>java -cp sci2lib.jar -server jnt.sci2.commandlineSciMark 2.0aComposite Score: 306.78196897286034 FFT (1024): 151.67309913043476 SOR (100x100): 387.8733963674583 Monte Carlo : 88.12720146546992 Sparse matmult (N=1000, nz=5000): 263.7263439793699 LU (100x100): 642.5098039215686java.vendor: Sun Microsystems Inc. java.version: 1.6.0 os.arch: x86 os.name: Windows 2000 os.version: 5.0C:\Documents and Settings\Administrator\桌面\sci2_1c>java -cp sci2lib.jar -server jnt.sci2.commandlineSciMark 2.0aComposite Score: 306.8051876391344 FFT (1024): 150.88587548285042 SOR (100x100): 390.38797784303205 Monte Carlo : 88.09828094822083 Sparse matmult (N=1000, nz=5000): 262.144 LU (100x100): 642.5098039215686java.vendor: Sun Microsystems Inc. java.version: 1.6.0 os.arch: x86 os.name: Windows 2000 os.version: 5.0------------------------------------------------------------------ C的结果 (VC 2005 Release)C:\Documents and Settings\Administrator\桌面\sci2_1c\test\Release>test ** ** ** SciMark2 Numeric Bench, see http://math.nist.gov/sci ** ** for details. (Results can be submitted to [email protected]) ** ** ** Using 2.00 seconds min time per kenel. Composite Score: 331.41 FFT Mflops: 188.53 (N=1024) SOR Mflops: 342.63 (100 x 100) MonteCarlo: Mflops: 60.08 Sparse matmult Mflops: 383.14 (N=1000, nz=5000) LU Mflops: 682.67 (M=100, N=100)C:\Documents and Settings\Administrator\桌面\sci2_1c\test\Release>test ** ** ** SciMark2 Numeric Bench, see http://math.nist.gov/sci ** ** for details. (Results can be submitted to [email protected]) ** ** ** Using 2.00 seconds min time per kenel. Composite Score: 325.71 FFT Mflops: 174.42 (N=1024) SOR Mflops: 342.51 (100 x 100) MonteCarlo: Mflops: 63.16 Sparse matmult Mflops: 371.20 (N=1000, nz=5000) LU Mflops: 677.25 (M=100, N=100)C:\Documents and Settings\Administrator\桌面\sci2_1c\test\Release>test ** ** ** SciMark2 Numeric Bench, see http://math.nist.gov/sci ** ** for details. (Results can be submitted to [email protected]) ** ** ** Using 2.00 seconds min time per kenel. Composite Score: 325.78 FFT Mflops: 174.42 (N=1024) SOR Mflops: 342.51 (100 x 100) MonteCarlo: Mflops: 63.64 Sparse matmult Mflops: 376.10 (N=1000, nz=5000) LU Mflops: 672.25 (M=100, N=100)差距缩小了很多， 不过总的来说还是C程序稍快
回复人：gtlang78() ( 两星(中级)) 信誉：100 ===================================== 你这只是计算了其中的一项，就如同奥运会几百个项目你只比了几项。你看我给出的证据中，都是比较了许多项才得出Java比C++快的结论的：浮点、整数、矩阵、数组、IO、异常、三角函数、循环、字符串等等许多方面的比较，java和C++互有胜负，但总体上java获胜项更多，所以才说java更快，而不是单说java的某个方面。而且，即使是比较某个单项方面，也是用了许多种评测程序来测量，多数评测程序证明java获胜，最终才说java获胜，而不是说用某个评测程序比较java获胜才说java获胜。比如： http://www.idiom.com/~zilla/Computer/javaCbench.html http://www.shudo.net/jit/perf/ http://www.javaworld.com/javaworld/jw-02-1998/jw-02-jperf_p.html http://www.kano.net/javabench/data http://www.tommti-systems.de/go.html?http://www.tommti-systems.de/main-Dateien/reviews/languages/benchs.html http://cpp.student.utwente.nl/bench/就用你测量的结果来说,5项评测中，java获胜2项，C++获胜3项，综合来说，C++胜，但其它方面比如浮点、整数、矩阵、数组、IO、异常、三角函数、循环、字符串等等的评测结果呢？ Java: FFT (1024): 150.88587548285042 SOR (100x100): 390.38797784303205 Monte Carlo : 88.09828094822083 Sparse matmult (N=1000, nz=5000): 262.144 LU (100x100): 642.5098039215686C++ FFT Mflops: 188.53 (N=1024) SOR Mflops: 342.63 (100 x 100) MonteCarlo: Mflops: 60.08 Sparse matmult Mflops: 383.14 (N=1000, nz=5000) LU Mflops: 682.67 (M=100, N=100) 最起码你已经见识到java的实力了，Monte Carlo这一项java的性能竟是C++的88/60=147.7% ！Java比C++快了近50%！ 而C++比java领先最多的是Sparse matmult这一项，C++的性能是Java的 383.14/262.144=146.2% 也就是说：Java最快的项比C++快47.7%,而C++最快的项只比java快46.2%。你还觉得java比C++慢吗？
test(0,0,0); printf("Number of solutions is %ld, %d seconds\n", sum,(int)(time(0)-tm)); }在2.3G的P4上运行结果是:E:\USBTEST\mycode>eightqueen 8 Queens Number of solutions is 92, 0 secondsE:\USBTEST\mycode>eightqueen 10 10 Queens Number of solutions is 724, 0 secondsE:\USBTEST\mycode>eightqueen 12 12 Queens Number of solutions is 14200, 0 secondsE:\USBTEST\mycode>eightqueen 15 15 Queens Number of solutions is 2279184, 4 secondsE:\USBTEST\mycode>eightqueen 16 16 Queens Number of solutions is 14772512, 29 seconds就是求16皇后的14772512种解只要29秒钟。哪位不服气可以用java写一下，看能不能达到C语言1/5的速度。
呵呵，让我来测吧，把 hai1039 兄的C++ 代码翻译成了java代码， 最后结果是 C++程序21秒，java程序是24秒， 虽然没有C++的快，但是显然远远超过了1/5以下是代码和输出结果 public class Queen { static int sum = 0, upperlim = 1; private static void test(int row, int ld, int rd) { if (row != upperlim) { int pos = upperlim & ~(row | ld | rd); while (pos != 0) { int p = pos & -pos; pos -= p; test(row + p, (ld + p) << 1, (rd + p) >> 1); } } else sum++; } public static void main(String[] args) { int n = 8; if (args.length == 1) n = Integer.parseInt(args[0]); long tm = System.currentTimeMillis(); if ((n < 1) || (n > 32)) { System.out.println(" heh..I can't calculate that."); System.exit(-1); } System.out.println(n + " Queens"); upperlim = (upperlim << n) - 1; test(0, 0, 0); System.out.println("Number of solutions is " + sum + ", " + (System.currentTimeMillis() - tm) + " milliseconds"); } }------------------------------------- C++ 的结果 (VC 2003 Release)C:\Documents and Settings\xxxxxxxx\桌面\queen\Release>queen 16 16 Queens Number of solutions is 14772512, 21 secondsC:\Documents and Settings\xxxxxxxx\桌面\queen\Release>queen 16 16 Queens Number of solutions is 14772512, 21 secondsC:\Documents and Settings\xxxxxxxx\桌面\queen\Release>queen 16 16 Queens Number of solutions is 14772512, 21 seconds ------------------------------------------- Java的结果 (java 1.6 -server)C:\Documents and Settings\xxxxxxxx\桌面\queen>java Queen 16 16 Queens Number of solutions is 14772512, 24358 millisecondsC:\Documents and Settings\xxxxxxxx\桌面\queen>java Queen 16 16 Queens Number of solutions is 14772512, 24139 millisecondsC:\Documents and Settings\xxxxxxxx\桌面\queen>java Queen 16 16 Queens Number of solutions is 14772512, 24139 milliseconds
抱歉抱歉，上面的java运行结果忘了加 -server了，不过加上了重新测的结果反而慢了一些，28秒多C:\Documents and Settings\xxxxxxxx\桌面\queen>java -server Queen 16 16 Queens Number of solutions is 14772512, 28748 millisecondsC:\Documents and Settings\xxxxxxxx\桌面\queen>java -server Queen 16 16 Queens Number of solutions is 14772512, 28717 millisecondsC:\Documents and Settings\xxxxxxxx\桌面\queen>java -server Queen 16 16 Queens Number of solutions is 14772512, 28795 milliseconds
楼主，你说的那个计算PI的程序(http://www.tempest-sw.com/bench/)我也测了，结果还是一样的，C程序稍快(VC2003 Release 单位:秒) ----------------------------------------------C:\Documents and Settings\xxxxxxx\桌面\pi\pi_c\Release>pi_c 20000 Time=37 0314159265358979323846264338327950288419716939937510......C:\Documents and Settings\xxxxxxx\桌面\pi\pi_c\Release>pi_c 20000 Time=37 0314159265358979323846264338327950288419716939937510......C:\Documents and Settings\xxxxxxx\桌面\pi\pi_c\Release>pi_c 20000 Time=37 0314159265358979323846264338327950288419716939937510......(Java 1.6 -server 单位:毫秒) -----------------------------------------C:\Documents and Settings\xxxxxxx\桌面\pi>java -server Pi 20000 Time=39935 0314159265358979323846264338327950288419716939937510......C:\Documents and Settings\xxxxxxx\桌面\pi>java -server Pi 20000 Time=39997 0314159265358979323846264338327950288419716939937510......C:\Documents and Settings\xxxxxxx\桌面\pi>java -server Pi 20000 Time=40044 0314159265358979323846264338327950288419716939937510......
虚拟机的速度和Java平台的速度是两个概念，虚拟机速度是有上限的，它不可能快过C/或者汇编，这是极限，就像C/汇编不可能快过机器码一样。Java平台是包括虚拟机在内、各种类库实现的速度，比如说虚拟机可能和C一样快，但是如果某个类库的某个算法不正确，速度在这儿可能就会慢几个数量级，因此，如果在这儿改进实现算法，就有可能在这个地方获得几个数量级速度的提高，但这显然和虚拟机的速度提高是两回事，我看过原文，这儿后面的评论已经说的很明白了，是Java2D部分提高，并不是整体平台能提高那么多，实际上如果整体平台能提高20%-40%就以经非常惊人了。目前的实际状况是：
1.虚拟机的速度达到或者接近普通C++编译器得到的效果。比C肯定还要差一些。
2.平台总体水平比java 5提高20-40%，这是不错的成就。
3.不排除平台的某些部分提高几倍的速度，比如Java2D渲染（有可能利用图形加速方面的接口），但也不排除某些部分根本一点速度没有提高，甚至为了其他部分速度的提高而牺牲这儿的速度。
4.这次整个平台速度提高主要归结为几个原因：a.虚拟机自动优化有一定的改进b.java并发包的算法改进使得使用该并发功能的部分都有所提高。c.Swing本身的改进和Java2D的改进。
http://www.ukhec.ac.uk/events/javahec/pozo.pdf
作者：美国国家标准科技研究院
java:C=7:5
==============
结论：大多数情况下，java更快
http://www.idiom.com/~zilla/Computer/javaCbench.html
作者：美国南加州大学计算机图形与Immersive技术实验室J.P.Lewis and Ulrich Neumann：
Java领先
=========
结论：大多数测试中java获胜
http://www.shudo.net/jit/perf/
FFT ， SOR，Monte Carlo， Sparse matmult，LU 这5个Bench的结果：
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
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项Bench中，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/benchs.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/bench/
结果：
14个Bench中
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大会，２００１年在斯坦福大学召开 ）
更惊人的是：在使用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甚至连数学计算的性能也超过了Ｃ＋＋
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编译器以３：２战胜Fortran 90
Fortran90:Java的结果（单位为秒）
20:14
40:30
440:444
1080:1089
11790:11690
输了的两项是以不到！％的差距输的
而赢了的三项中有两项是以３３％以上的差距获胜的
文章中的结论： 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.
当今最好的ＪＩＴ编译器可以产生性能接近甚至超过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 benchs＞＞
其中对比了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性能大大超过用Ｃ写的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
这是ＳＵＮ对比J2EE与.net的Bench报告：
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个Bench的结果：
＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆＆
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快４０％到９０％ 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的版本提高都带来性能的极大提升。所以如果你在某处看到一个bench说Ｃ＋＋比java快，那就很可能是用的老版本的java。
但是Ｃ＋＋近年似乎没什么速度的提升
http://java.sun.com/j2se/1.4.2/1.4.2_whitepaper.html
http://community.csdn.net/Expert/TopicView3.asp?id=3636713 请认为本贴有价值的人将本贴存在自己的电脑中（用ＩＥ可能无法直接存储，请用FireFox存储，或全选本文再存成txt文件） C++的速度是由C++编译器在程序员开发时编译出来的机器语言的优化程度决定的。
Java的速度是由Java的JIT和HotSpot编译器将java bytecode在运行时“即时”编译成针对本地CPU的优化的本地代码决定的。 比速度的实际就是在比：看C++编译器和java编译器谁能产生更优化的机器代码。
很明显，C++的编译器不如java的JIT和HotSpot编译器，因为JIT和HotSpot编译器能针对CPU指令集进行人优化、能在运行时根据使用频率对method进行内联和优化。而C++的静态编译器永远也做不到这些 两者有着本质的不同，但是有些Qpper用一辈子也无法理解这其中的差别，
他们只能抱着一个可怜的、没有任何根据“C++比Java快”终其一生
以下是Java比Ｃ＋＋快的理论依据：
关于java如此快的原因：
有些东西确实只有JIT能做到： 比如中提到：
http://www.idiom.com/~zilla/Computer/javaCbench.html The compiler knows what processor it is running on, and can generate code specifically for that processor。
JIT编译器知道什么处理器正在运行，可以产生对应此处理器的优化代码。在这一点上，C++的静态编译器肯定做不到。
# The compiler knows what processor it is running on, and can generate code specifically for that processor. It knows whether (for example) the processor is a PIII or P4, if SSE2 is present, and how big the caches are. A pre-compiler on the other hand has to target the least-common-denominator processor, at least in the case of commercial software.
JIT编译器知道什么处理器正在运行，可以产生对应此处理器的优化代码。它知道是否处理器是P3或P4，是否SSE2存在，cache有多大。一个C++之类的预先编译器只能针对所有处理器的指令集的“最小公分母”进行编译，至少在商业软件中是这样的。
# Because the compiler knows which classes are actually loaded and being called, it knows which methods can be de-virtualized and inlined. (Reably, modern java compilers also know how to "uncompile" inlined calls in the case where an overriding method is loaded after the JIT compilation happens.)
因为JIT编译器知道哪些类被实际装载和调用，它知道哪些方法可以被“消虚拟化(de-virtualized)”
和内联(值得一提的是：当代java编译器还能知道在被覆盖的方法被装载的情况下，在JIT编译后进行“逆编译”内联的方法调用)
# A dynamic compiler may also get the branch prediction hints right more often than a static compiler.
动态编译器可以进行更多的分支预测
重点强调：
＊＊＊
Java速度如此快的原因在此（来源：IBM东京研究院）
http://www.is.titech.ac.jp/ppl2004/proceedings/ishizaki_slides.pdf
＊＊＊
其中有6大步优化，
每个大步中又有若干小步的优化，
共几十步的优化。
自己看吧，英语比较简单，只是内函比较难理解，
如果自己看不明白，别人解释也一样听不懂。
但他们却在有意回避一个事实： 用C++编译器编译出来的本地代码才是C++程序
用Fortran编译器编译出来的本地代码才是Fortran程序
用Delphi编译器编译出来的本地代码才是Delphi程序
用C#编译器编译出来的本地代码才是C#程序
用VB.net编译器编译出来的本地代码才是VB.net程序
用Java编译器编译出来的本地代码才是Java程序 如果照某些Qpper的观点，那么世界上只有机器语言一种语言，因为其它语言归根结底都是机器语言程序，岂不荒唐？
而Java的本地代码是用Java的JIT和HotSpot编译器在程序运行时编译出来的，根本不是C++编译器编译出来的，所以java程序根本不是一个Ｃ＋＋程序！
JIT和HotSpot编译器可以根据程序运行的CPU进行指令集进行优化，C++编译器可以吗？
JIT和HotSpot编译器可以根据程序运行时的profile对本地代码进行inline等优化，C++编译器可以吗？
JIT和HotSpot编译器可以根据程序运行时根据程序运行的情况进行更准确的分支预测，C++编译器可以吗？
大家可以去jre1.5.0的安装路径中去看看：
其中的jar文件共有５０.5Ｍ，由于jar文件是压缩文件，并且bytecode的代码要比native code精简的多(前面已经说过了：一个构造方法在bytecode中只要一个指令，构造方法在C++的编译器却要11个指令。Java 一個 method call 只要一個machine code，但用 x86 相對需要 4 個)，所以这５０.5Ｍ的java程序完成的工作大约相当于２００Ｍ以上的本地代码完成的工作。
而其中的.exe和.dll共有7.7M,本地代码在java运行环境中占的比例连５％都不到。 而这仅有的５％的“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快”终其一生
Qpper们，上台继续表演“阿Ｑ精神胜利法”吧！
欢迎到我的博客来看看：
http://blog.sina.com.cn/u/1264601020
节选： c++ 的 virtaul method calling：
不算 argument 4 個指令 c 的一般 call：
不算 argument 2 個指令 java 的 virtual call：
不算 argument 2 個指令. c++ 的 constructor：
11 個指令 C++ destructor：
8 個指令 java 的 constructor：
2 個指令 由此可發現，對動態配置物件的操作而言，Java 一個 method call 只要一個
machine code，但用 x86 相對需要 4 個，這是 Java 在指令集層面直接支援所致。
Joakim Dahlstedt 的來頭可不小，是 JRockit VM 的主要設計者，現任 BEA System
裡頭 Java Runtime Group 的技術長，這篇文章並非老王賣瓜，相反的，Joakim 要
我們明瞭，評斷 Java VM "bench" (效能評比) 的方式需要調整，主要是基於以
下幾項： 1.一般的 bench 比較僅僅是 micro-bench level，不能推廣到 system-
level。
2.軟體產業開發方式發生了很大的變化，大量使用 class library、framework、
Application server，乃至 Web services。援引舊的 bench 僅能針對其中
個別 software stack，卻不能進行 system-level 的全面分析，如此的衡量本
身就有問題。
3.Java VM 本身的 Dynamic Optimization，可依據最真實的 profiling 數據調整
元件，使其針對效能進行重組。
4.最後，新的 CPU 架構，像是 Intel EPIC 可能更適合於 Dynamic Optimization
，而非傳統 static compiler。在 EPIC 的架構下，compiler 對效能的影響相
當大，compiler 有責任選擇平行處理的指令集，而非像傳統 Pentium 引入自動
的 out-of-order 亂序執行支援，這意味著，軟體支配了 EPIC 的效能，這對
static compiler 是不利的，因為僅能從 bytecode 取得固定的統計與符號，卻
未能對真實 profiling 作規劃。 Joakim 的結論給予我們很好的啟發： "In conclusion, ..., but I hope I've convinced you that using runtime
systems like Sun Microsystems' HotSpot or BEA WebLogic JRockit Java
is not slow or inefficient, and that the performance of a large-scale
system built with Java may be superior to that of the same system
built using C." IBM 的 JDK 曾經一度是最佳性能的 Java VM，但 Sun JDK 1. 4的性能已與 IBM JDK
1.3 相當，其 server 版採用更積極的 JIT 和 GC (Garbage Collection) 技術，尤
其是針對 SMP 的應用提供最適合該硬體架構與多執行緒處理的 GC。 在另一方面，IBM 將內部的 Jalapeno JVM 研究計畫 [6] 的成果以 Open Source 授
權釋出的 JikesRVM 計畫 [7]，提供一個測試許多 JIT 與 GC 等技術與演算法的參
考實作平台。IBM Rearch 將 JikesRVM 視作 JIT 方面的一個 research infrastru-
cture，在網站上羅列了相當豐富的論文可參考 。筆者參考了 JikesRVM 的研究方向
，認為 JIT Compiler 發展趨勢可列出以下：
1. 類似於 Hotspot [8] 整合 base interpreter、profiling，以及 adaptive
compiler 三種技術的途徑。
2. 動態 profiling 技術，從簡單的 counter-based algorithm 進化到
performance monitoring event。
3. 應用靜態 compiler 中更 aggressive 的編譯技術 (對 JIT Compiler 而言，
編譯時間已是次要問題)，產生最佳化原生碼 (native code)。
4. 應用 inter-procedural 分析，例如 escape analysis 可以 remove synchro-
nization 和實施 stack allocation。
5. 參考 Runtime 所獲得的資訊 (主要是 metadata 和 dynamic allocation)，產
生最佳化原生碼。 [6] http://www.research.ibm.com/jalapeno/
[7] http://www-124.ibm.com/developerworks/oss/jikesrvm/
[8] http://java.sun.com/products/hotspot/ 接著，我們來看看 Sun 的 Hotspot 技術。提到 Hotspot 不能不提 Henry Massalin
這位先驅，Henry 的博士論文在 Java Glossary 的 HotSpot 的解釋 [9] 中被譽為
"the mother of all self-modifying code"，同時，HotSpot 也是 "builds heavily
on work done in a PhD thesis by Henry Massalin"。 [9] http://mindprod.com/jgloss/hotspot.html Java 最初的實作是透過直譯器 (interpreter)，但這並非意味 Java 一定被解譯執
行的。早期的 Java VM 的確是逐一指令的解譯，因此效能極不理想，於是引入了
JIT 等關鍵技術，而 HotSpot 可說下個世代的 JIT。據 Sun 官方文獻指出，使用
HotSpot 的 Java VM 在 Runtime 時期已經很難分辨 Java bytecode 是否被 JVM 解
釋執行了，因為 HotSpot 實際上是把 Java 的bytecode 編譯成原生碼執行了。
實際上，在 HotSpot 設計中，有兩個技術是相當重要的，也就是所謂 dynamic
compilation 和 profiling。HotSpot 對 bytecode 的編譯，並非在程式執行前預先
編譯的 (這種傳統的方式相對而言稱為 static compilation)，相反的，是在程式執
行過程中，以 HotSpot 內建的編譯器做動態的編譯，早期的 JIT(Just In Time) 其
實也是如此的概念，不過沒有 HotSpot 來得全面性。 那麼，HotSpot 是如何動態編譯 Java bytecode 呢﹖HotSpot 採用一個高度彈性的
設計，內部維護了 Profile Monitor，專門監視程式執行中，判斷程式片段中使用的
頻率高寡，並依據對性能影響的程度，交付於若干演算法處理。HotSpot 對於那些對
程式執行時效率影響較大的程式碼片段，特稱為 hot spot (特別以小寫書寫，避免
與 HotSpot 混淆)，HotSpot 會這些片段動態編譯成原生碼，同時，會依據之前
profiling 的結果，對這些原生碼進行最佳化，從而提高執行效率。相反的，如果執
行頻率較低的程式碼片段，HotSpot 就沒必要花時間做動態編譯，只需要以直譯器執
行即可。 整體而論，在 HotSpot 下，Java bytecode 是以解譯的方式被載入到 JavaVM 中，
但是 HotSpot 立刻會依據某些程式碼片段執行的狀態，獲知其中對效能影響最大的
部分，透過動態編譯與最佳化處理，建立原生碼，於是，接下來的執行過程中就可獲
得相當程度的效能提昇。我們可以得知，HotSpot 對 bytecode 的執行有以下三種處
理方式：
- 直譯 (不動態編譯)
- 部分動態編譯
- 依據 profiling 結果做動態編譯與最佳化處理
至於程式哪部分只做直譯、部分動態編譯，以及哪部分做何種最佳化處理，則全程由
Profile Monitor 決定。
採用 dynamic compilation 會比傳統的 static compilation 帶來什麼優點呢？撇
開跨平台需求不論，dynamic compilation 在許多方面優越於傳統的途徑，特別是
profiling 的能力。過去 static compilation 很難精準的預知程式執行中究竟何處
才是最需要最佳化處理的部分，僅能透過內建的 template 來建構 micro-level 的
最佳化程式碼。相反的，dynamic compilation 可獲悉最真實的 profiling 表現，
依據需求動態調整，這在日後處理器逐漸軟體化的發展趨勢而言，更顯得重要，因為
過去硬體的工作逐漸移轉到軟體來做，compiler optimization 的責任就格外沈重了
，像是前述 Intel EPIC 架構。 另一個典型的例子，稱為 method inlining。無論是在 C++ 或是 Java 中，呼叫
(invoke) method 是很消耗系統資源的，系統必須維護堆疊操作，以符合預期的
calling convention。於是，有人提出把原本需要做 method invocation 的處理，
改用 inline 的方式，「嵌入」到原本呼叫的地方，如此一來，就只是單純的循序執
行，也不會有堆疊操作。但是，method inlining 的方式對 C++ 與 Java 一類的物
件導向語言來說，編譯器很難有很好的實作方式，因為需要兼顧物件導向的特徵，尤
其是維持 dynamic binding 性質。static compiler 其實可以把 C++/Java 中屬性
為 private 與 static 的 method 做 method inlinng，但是一旦有 overridden 或
dynamic binding 時，static compiler 無法得知實際上的執行狀況，就會保守的不
予實施 inlining。這個難題，恰好可被 HotSpot 一類 dynamic compilation 的設
計迎刃而解，因為 Profiling Monitor 對 method invocation 的狀況可以掌握，當
然可精準的得知 Runtime 中，RTTI (Run-Time Type Identification) 可協助
HotSpot 處理 method inlining，因此，在 server-side 應用這種重複進行某項目
執行時，可獲得頗大的效能提昇。 Sun 的文獻也指出，在某些狀況下，Java 的應用程式甚至可比傳統的 C 程式還快。 以目前發展而言，JIT Compiler 的成本主要在於 profiling 與 dynamic compila-
tion 兩項。理想而言，這兩項成本應該視為 constantant time，於是許多研究論文
相繼提出，以作為效能改進。特製為 JIT Compiler 使用、精度不需很高的 Java
Runtime profiling 可參考〈A Portable Samplling-Based Profiler for Java
Virtual Machines〉[10]，該論文提出採用 sampling 的方式來做近似分析。而至於
Dynamic compilation 的 overhead 可以用漸進式最佳化的方式來減少，在 Sun 的
HotSpot 白皮書已有詳盡的介紹。 全文
http://dev.csdn.net/develop/article/54/54057.shtm
据我自己的实践，这种说法确实成立。然而，我也发现许多关于速度的怀疑都来自一些早期的实现方式。由于这些方式并非特别有效，所以没有一个模型可供参考，不能解释Java速度快的原因。
我之所以想到速度，部分原因是由于C++模型。C++将自己的主要精力放在编译期间“静态”发生的所有事情上，所以程序的运行期版本非常短小和快速。C+ +也直接建立在C模型的基础上（主要为了向后兼容），但有时仅仅由于它在C中能按特定的方式工作，所以也是C++中最方便的一种方法。最重要的一种情况是 C和C++对内存的管理方式，它是某些人觉得Java速度肯定慢的重要依据：在Java中，所有对象都必须在内存“堆”里创建。
而在C++中，对象是在堆栈中创建的。这样可达到更快的速度，因为当我们进入一个特定的作用域时，堆栈指针会向下移动一个单位，为那个作用域内创建的、以堆栈为基础的所有对象分配存储空间。而当我们离开作用域的时候（调用完毕所有局部构建器后），堆栈指针会向上移动一个单位。然而，在C++里创建 “内存堆”（Heap）对象通常会慢得多，因为它建立在C的内存堆基础上。这种内存堆实际是一个大的内存池，要求必须进行再循环（再生）。在C++里调用 delete以后，释放的内存会在堆里留下一个洞，所以再调用new的时候，存储分配机制必须进行某种形式的搜索，使对象的存储与堆内任何现成的洞相配，否则就会很快用光堆的存储空间。之所以内存堆的分配会在C++里对性能造成如此重大的性能影响，对可用内存的搜索正是一个重要的原因。所以创建基于堆栈的对象要快得多。
同样地，由于C++如此多的工作都在编译期间进行，所以必须考虑这方面的因素。但在Java的某些地方，事情的发生却要显得“动态”得多，它会改变模型。创建对象的时候，垃圾收集器的使用对于提高对象创建的速度产生了显著的影响。从表面上看，这种说法似乎有些奇怪——存储空间的释放会对存储空间的分配造成影响，但它正是JVM采取的重要手段之一，这意味着在Java中为堆对象分配存储空间几乎能达到与C++中在堆栈里创建存储空间一样快的速度。
可将C++的堆（以及更慢的Java堆）想象成一个庭院，每个对象都拥有自己的一块地皮。在以后的某个时间，这种“不动产”会被抛弃，而且必须再生。但在某些JVM里，Java堆的工作方式却是颇有不同的。它更象一条传送带：每次分配了一个新对象后，都会朝前移动。这意味着对象存储空间的分配可以达到非常快的速度。“堆指针”简单地向前移至处女地，所以它与C++的堆栈分配方式几乎是完全相同的（当然，在数据记录上会多花一些开销，但要比搜索存储空间快多了）。
现在，大家可能注意到了堆事实并非一条传送带。如按那种方式对待它，最终就要求进行大量的页交换（这对性能的发挥会产生巨大干扰），这样终究会用光内存，出现内存分页错误。所以这儿必须采取一个技巧，那就是著名的“垃圾收集器”。它在收集“垃圾”的同时，也负责压缩堆里的所有对象，将“堆指针”移至尽可能靠近传送带开头的地方，远离发生（内存）分页错误的地点。垃圾收集器会重新安排所有东西，使其成为一个高速、无限自由的堆模型，同时游刃有余地分配存储空间。
为真正掌握它的工作原理，我们首先需要理解不同垃圾收集器（GC）采取的工作方案。一种简单、但速度较慢的GC技术是引用计数。这意味着每个对象都包含了一个引用计数器。每当一个句柄同一个对象连接起来时，引用计数器就会增值。每当一个句柄超出自己的作用域，或者设为null时，引用计数就会减值。这样一来，只要程序处于运行状态，就需要连续进行引用计数管理——尽管这种管理本身的开销比较少。垃圾收集器会在整个对象列表中移动巡视，一旦它发现其中一个引用计数成为0，就释放它占据的存储空间。但这样做也有一个缺点：若对象相互之间进行循环引用，那么即使引用计数不是0，仍有可能属于应收掉的“垃圾”。为了找出这种自引用的组，要求垃圾收集器进行大量额外的工作。引用计数属于垃圾收集的一种类型，但它看起来并不适合在所有JVM方案中采用。
在速度更快的方案里，垃圾收集并不建立在引用计数的基础上。相反，它们基于这样一个原理：所有非死锁的对象最终都肯定能回溯至一个句柄，该句柄要么存在于堆栈中，要么存在于静态存储空间。这个回溯链可能经历了几层对象。所以，如果从堆栈和静态存储区域开始，并经历所有句柄，就能找出所有活动的对象。对于自己找到的每个句柄，都必须跟踪到它指向的那个对象，然后跟随那个对象中的所有句柄，“跟踪追击”到它们指向的对象……等等，直到遍历了从堆栈或静态存储区域中的句柄发起的整个链接网路为止。中途移经的每个对象都必须仍处于活动状态。注意对于那些特殊的自引用组，并不会出现前述的问题。由于它们根本找不到，所以会自动当作垃圾处理。
在这里阐述的方法中，JVM采用一种“自适应”的垃圾收集方案。对于它找到的那些活动对象，具体采取的操作取决于当前正在使用的是什么变体。其中一个变体是“停止和复制”。这意味着由于一些不久之后就会非常明显的原因，程序首先会停止运行（并非一种后台收集方案）。随后，已找到的每个活动对象都会从一个内存堆复制到另一个，留下所有的垃圾。除此以外，随着对象复制到新堆，它们会一个接一个地聚焦在一起。这样可使新堆显得更加紧凑（并使新的存储区域可以简单地抽离末尾，就象前面讲述的那样）。
当然，将一个对象从一处挪到另一处时，指向那个对象的所有句柄（引用）都必须改变。对于那些通过跟踪内存堆的对象而获得的句柄，以及那些静态存储区域，都可以立即改变。但在“遍历”过程中，还有可能遇到指向这个对象的其他句柄。一旦发现这个问题，就当即进行修正（可想象一个散列表将老地址映射成新地址）。
有两方面的问题使复制收集器显得效率低下。第一个问题是我们拥有两个堆，所有内存都在这两个独立的堆内来回移动，要求付出的管理量是实际需要的两倍。为解决这个问题，有些JVM根据需要分配内存堆，并将一个堆简单地复制到另一个。
第二个问题是复制。随着程序变得越来越“健壮”，它几乎不产生或产生很少的垃圾。尽管如此，一个副本收集器仍会将所有内存从一处复制到另一处，这显得非常浪费。为避免这个问题，有些JVM能侦测是否没有产生新的垃圾，并随即改换另一种方案（这便是“自适应”的缘由）。另一种方案叫作“标记和清除”， Sun公司的JVM一直采用的都是这种方案。对于常规性的应用，标记和清除显得非常慢，但一旦知道自己不产生垃圾，或者只产生很少的垃圾，它的速度就会非常快。
标记和清除采用相同的逻辑：从堆栈和静态存储区域开始，并跟踪所有句柄，寻找活动对象。然而，每次发现一个活动对象的时候，就会设置一个标记，为那个对象作上“记号”。但此时尚不收集那个对象。只有在标记过程结束，清除过程才正式开始。在清除过程中，死锁的对象会被释放然而，不会进行任何形式的复制，所以假若收集器决定压缩一个断续的内存堆，它通过移动周围的对象来实现。
“停止和复制”向我们表明这种类型的垃圾收集并不是在后台进行的；相反，一旦发生垃圾收集，程序就会停止运行。在Sun公司的文档库中，可发现许多地方都将垃圾收集定义成一种低优先级的后台进程，但它只是一种理论上的实验，实际根本不能工作。在实际应用中，Sun的垃圾收集器会在内存减少时运行。除此以外，“标记和清除”也要求程序停止运行。
正如早先指出的那样，在这里介绍的JVM中，内存是按大块分配的。若分配一个大块头对象，它会获得自己的内存块。严格的“停止和复制”要求在释放旧堆之前，将每个活动的对象从源堆复制到一个新堆，此时会涉及大量的内存转换工作。通过内存块，垃圾收集器通常可利用死块复制对象，就象它进行收集时那样。每个块都有一个生成计数，用于跟踪它是否依然“存活”。通常，只有自上次垃圾收集以来创建的块才会得到压缩；对于其他所有块，如果已从其他某些地方进行了引用，那么生成计数都会溢出。这是许多短期的、临时的对象经常遇到的情况。会周期性地进行一次完整清除工作——大块头的对象仍未复制（只是让它们的生成计数溢出），而那些包含了小对象的块会进行复制和压缩。JVM会监视垃圾收集器的效率，如果由于所有对象都属于长期对象，造成垃圾收集成为浪费时间的一个过程，就会切换到“标记和清除”方案。类似地，JVM会跟踪监视成功的“标记与清除”工作，若内存堆变得越来越“散乱”，就会换回“停止和复制”方案。“自定义”的说法就是从这种行为来的，我们将其最后总结为：“根据情况，自动转换停止和复制／标记和清除这两种模式”。
JVM还采用了其他许多加速方案。其中一个特别重要的涉及装载器以及JIT编译器。若必须装载一个类（通常是我们首次想创建那个类的一个对象时），会找到.class文件，并将那个类的字节码送入内存。此时，一个方法是用JIT编译所有代码，但这样做有两方面的缺点：它会花更多的时间，若与程序的运行时间综合考虑，编译时间还有可能更长；而且它增大了执行文件的长度（字节码比扩展过的JIT代码精简得多），这有可能造成内存页交换，从而显著放慢一个程序的执行速度。另一种替代办法是：除非确有必要，否则不经JIT编译。这样一来，那些根本不会执行的代码就可能永远得不到JIT的编译。
由于JVM对浏览器来说是外置的，大家可能希望在使用浏览器的时候从一些JVM的速度提高中获得好处。但非常不幸，JVM目前不能与不同的浏览器进行沟通。为发挥一种特定JVM的潜力，要么使用内建了那种JVM的浏览器，要么只有运行独立的Java应用程序。
http://pub.chinans-ls.com/~jx/java/chapter/appe.htm
Java虚拟机的确在有些地方快于C++(普通C++编译器)，但是程序指令码的执行速度有个个极限，最终是平台实现的速度比较，但是在平台实现上了，这两者没有办法比较，毕竟两者的东西不是一对一的。
而且Java和C++适用于不同领域，不好比较。做科学计算也许是最可比较的地方，这个领域实际在比编译器和虚拟机的优劣。
但他们却在有意回避一个事实：用C++编译器编译出来的本地代码才是C++程序
用Fortran编译器编译出来的本地代码才是Fortran程序
用Delphi编译器编译出来的本地代码才是Delphi程序
用C#编译器编译出来的本地代码才是C#程序
用VB.net编译器编译出来的本地代码才是VB.net程序
用Java编译器编译出来的本地代码才是Java程序如果照某些Qpper的观点，那么世界上只有机器语言一种语言，因为其它语言归根结底都是机器语言程序，岂不荒唐？
而Java的本地代码是用Java的JIT和HotSpot编译器在程序运行时编译出来的，根本不是C++编译器编译出来的，所以java程序根本不是一个Ｃ＋＋程序！
JIT和HotSpot编译器可以根据程序运行的CPU进行指令集进行优化，C++编译器可以吗？
JIT和HotSpot编译器可以根据程序运行时的profile对本地代码进行inline等优化，C++编译器可以吗？
JIT和HotSpot编译器可以根据程序运行时根据程序运行的情况进行更准确的分支预测，C++编译器可以吗？
大家可以去jre1.5.0的安装路径中去看看：
其中的jar文件共有５０.5Ｍ，由于jar文件是压缩文件，并且bytecode的代码要比native code精简的多(前面已经说过了：一个构造方法在bytecode中只要一个指令，构造方法在C++的编译器却要11个指令。Java 一個 method call 只要一個machine code，但用 x86 相對需要 4 個)，所以这５０.5Ｍ的java程序完成的工作大约相当于２００Ｍ以上的本地代码完成的工作。
而其中的.exe和.dll共有7.7M,本地代码在java运行环境中占的比例连５％都不到。而这仅有的５％的“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快”终其一生
Qpper们，上台继续表演“阿Ｑ精神胜利法”吧！
我也是支持Java的，当然很高兴看到Java能和C++并肩，只是觉得总体来说说Java速度超过C++还为时过早，只能说某些领域，比如科学计算。我认为现在Java总体速度能赶上普通C++编译器的速度了。
而且速度这个东西很难界定义：是虚拟机本身的速度？编译器产生代码的速度？运行时平台的速度？还是应用程序本身的速度？
一个应用系统的速度取决于太多的因素：1.机器（语言比较时可以刨掉）2.虚拟机（C++没有、Java由于JIT/Hotspot的采用也变化多样）3.编译器（编译器产生的指令的优化程度）4.平台的实现（具体类库的实现，包括它们的算法等因素，Java有一个庞大的类库，C++这一层很薄，有些部分进入应用层）5.应用程序本身的实现。所以严格意义上两种语言平台是没有办法比较的。于是人们就尽量去掉影响因素，比如应用程序本身使用相同算法、大约相同的内存（去掉5），实现原子类型的操作（比如数学计算，这样可以大约去掉因素4，类库）、机器因素可以采用相同的机器配置（可以去掉1），因此，实际上人们在比较的是2和3。目前程度下我觉得只能说Java的2和3结合起来能达到相当于C++（还是普通C++编译器）的水平，超越C++的说法再大多数情况还是站不住脚的。
另外以后更新版本也没有所谓的1.x.x版本了，改成Java SE 6 update release x了。
Java 5就是Java SE 5，也就是JDK 1.5.x。Java以前的名字可真乱。
从版本1.5开始，Sun Java的平台都叫Java SE X，更新版叫Java SE X update release x了。
另外企业版改名叫Java EE X了，宏版叫Java ME X。
------------------------------------
没有发现代码 一堆理论有什么用 贴几段代码出来 我去试试 试后再讲其他话
1：启动速度
2：将Java字节码编译成二进制机器指定所需要的编译时间，这个编译器可以是JIT，也可以是HotSpot，或是最古老的解释器。
3：运行速度
4：内存回收速度。在比较Server端程序时，1和2其实是忽略不计的。在比较客户端程序时，我承认在1上，java目前是比不过c++的，至少java要先启动jvm。但将来有一天也许JVM和操作系统一同启动，这样java启动速度问题也可以解决。但有一点要说明，C++启动之所以快，有很大部分原因是C++程序运行时需要的许多.exe或.dll之类的文件在操作系统启动时或其它程序启动时局装入内存或已经启动了在4方面，前面我提到了一篇文章《很难相信Java居然能和C++一样快，甚至还能更快一些》，这就是讲java在内在回收方面的速度也可以和C++一样快甚至更快。而且内存在摩尔定律下越来越便宜，也不再是java担心的了而我相信，单就3来说，由于java可以根据运行时的情况进行优化，java已经整体上超过了C++。
我承认目前有一点上java的速度比不上c++，就是启动速度。java要先启动
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
你试试这些吧，都有代码的。有的是用的是标准的程序。
http://www.idiom.com/~zilla/Computer/javaCbench.html
http://www.shudo.net/jit/perf/
http://www.javaworld.com/javaworld/jw-02-1998/jw-02-jperf_p.html
http://www.kano.net/javabench/data
http://www.tommti-systems.de/go.html?http://www.tommti-systems.de/main-Dateien/reviews/languages/benchs.html
http://cpp.student.utwente.nl/bench/
http://www.ukhec.ac.uk/events/javahec/pozo.pdf
作者：美国国家标准科技研究院
java:C=7:5
==============
结论：大多数情况下，java更快这个文件中并没给出java代码，他们用的是美国国家标准科技研究院的标准性能评测程序。他们只给出了评测程序的名字，和来源：
http://math.nist.gov/sci其它的证据也是类似，如果没有给出源代码那么就用的是标准评测程序
public static void main(String[] args) {
long i,j,x,z;
double y,tmp1;
i=System.currentTimeMillis();
String str;
for(z=0; z<3; z++)
{
for (x = 0; x < 10000000 ; x++)
{
str="ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789~!@#$%^&*()_+";
}
for(y = 0.0; y <10000000.0 ; y++)
{
tmp1 = y/3.1415926;
}
}
j = System.currentTimeMillis();
System.out.println(j-i);
}
}JAVA JDK6 667豪秒
DEV-C++ 4。9。9。0 4500豪秒 服了
#include <iostream>
#include <stdlib.h>
#include <windows.h>
using namespace std;int main(int argc, char *argv[])
{
long i,j,x,z;
double y,tmp1;
i=GetTickCount();
string str;
for(z=0; z<3; z++)
{
for (x = 0; x < 10000000 ; x++)
{
str="ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789~!@#$%^&*()_+";
}
for(y = 0.0; y <10000000.0 ; y++)
{
tmp1 = y/3.1415926;
}
}
j = GetTickCount();
printf("%d",j-i);
system("PAUSE");
return 0;
}
最后的结果是5项测试里面只有一项java比C快C:\Documents and Settings\Administrator\桌面\sci2_1c>java -cp sci2lib.jar jnt.sci2.commandlineSciMark 2.0aComposite Score: 174.0996577855954
FFT (1024): 130.40076160821025
SOR (100x100): 235.33889206168786
Monte Carlo : 33.554432
Sparse matmult (N=1000, nz=5000): 171.92025020190837
LU (100x100): 299.28395305617056java.vendor: Sun Microsystems Inc.
java.version: 1.6.0
os.arch: x86
os.name: Windows 2000
os.version: 5.0C:\Documents and Settings\Administrator\桌面\sci2_1c>java -cp sci2lib.jar jnt.sci2.commandlineSciMark 2.0aComposite Score: 174.63467967379245
FFT (1024): 129.81844721921811
SOR (100x100): 235.33891947212564
Monte Carlo : 33.288126448727645
Sparse matmult (N=1000, nz=5000): 173.32980063389954
LU (100x100): 301.3981045949912java.vendor: Sun Microsystems Inc.
java.version: 1.6.0
os.arch: x86
os.name: Windows 2000
os.version: 5.0C:\Documents and Settings\Administrator\桌面\sci2_1c>java -cp sci2lib.jar jnt.sci2.commandlineSciMark 2.0aComposite Score: 175.01133040295787
FFT (1024): 129.81844721921811
SOR (100x100): 233.51369872149715
Monte Carlo : 33.554432
Sparse matmult (N=1000, nz=5000): 174.76266666666666
LU (100x100): 303.4074074074074java.vendor: Sun Microsystems Inc.
java.version: 1.6.0
os.arch: x86
os.name: Windows 2000
os.version: 5.0--------------------------------------------------------------------- 以下是C的结果
C:\Documents and Settings\Administrator\桌面\sci2_1c\test\Release>test
** **
** SciMark2 Numeric Bench, see http://math.nist.gov/sci **
** for details. (Results can be submitted to [email protected]) **
** **
Using 2.00 seconds min time per kenel.
Composite Score: 275.65
FFT Mflops: 140.98 (N=1024)
SOR Mflops: 185.78 (100 x 100)
MonteCarlo: Mflops: 43.61
Sparse matmult Mflops: 458.45 (N=1000, nz=5000)
LU Mflops: 549.43 (M=100, N=100)
C:\Documents and Settings\Administrator\桌面\sci2_1c\test\Release>test
** **
** SciMark2 Numeric Bench, see http://math.nist.gov/sci **
** for details. (Results can be submitted to [email protected]) **
** **
Using 2.00 seconds min time per kenel.
Composite Score: 275.68
FFT Mflops: 140.98 (N=1024)
SOR Mflops: 185.71 (100 x 100)
MonteCarlo: Mflops: 43.61
Sparse matmult Mflops: 458.45 (N=1000, nz=5000)
LU Mflops: 549.65 (M=100, N=100)
C:\Documents and Settings\Administrator\桌面\sci2_1c\test\Release>test
** **
** SciMark2 Numeric Bench, see http://math.nist.gov/sci **
** for details. (Results can be submitted to [email protected]) **
** **
Using 2.00 seconds min time per kenel.
Composite Score: 275.83
FFT Mflops: 141.67 (N=1024)
SOR Mflops: 185.78 (100 x 100)
MonteCarlo: Mflops: 43.59
Sparse matmult Mflops: 458.45 (N=1000, nz=5000)
LU Mflops: 549.65 (M=100, N=100)
谢谢楼上几位前辈，尤其是
gmdroc() ( ) 信誉：100 Blog
狂摆事实，非常感谢！让我了解了很多知识。我听到的JAVA不如C快，只是在3D领域，但是具体怎么样，
我真的没有实验过。期待着JAVA在速度上全面超越C的那一天！
我是不会相信的，如果有这种情况存在，也许可能是因为用c/cpp写一段比较烂的程序，
和java精心编写的并经过 JIT和HotSpot编译器 优化后的程序做比较，
根本就没有可比性而言。
如果java 的fans硬要认为即使没有经过优化的java代码也会比c/cpp要快，
那么建议学学汇编，顺便学学计算机原理之类的吧，不要人云亦云。=============ref start
C++的速度是由C++编译器在程序员开发时编译出来的机器语言的优化程度决定的。
Java的速度是由Java的JIT和HotSpot编译器将java bytecode在运行时“即时”编译成针对本地CPU的优化的本地代码决定的。比速度的实际就是在比：看C++编译器和java编译器谁能产生更优化的机器代码。
很明显，C++的编译器不如java的JIT和HotSpot编译器，因为JIT和HotSpot编译器能针对CPU指令集进行人优化、能在运行时根据使用频率对method进行内联和优化。而C++的静态编译器永远也做不到这些
============ref end
如果选定指令集对c/cpp和java都明确的话，两者的差别在哪儿？都产生同样的的目标代码，
动态编译难道比静态编译更牛一点？
难道一个c/cpp因为不支持某一个最新的cpu的某一个指令就一棒子打死？
要比较也要在同一基础下啊.
况且你可以使用 硬件体系结构相关选项 来选择cpu，
常用的cpu 应该都会在里面，如果没有的话 动态编译器也会存在同样的问题，可能程度会低一点而已，我就不信新出的cpu动态编译器也能利用他的新指令特性来优化？
==========ref start
能在运行时根据使用频率对method进行内联和优化
==========ref end
收集优化的证据的成本算谁的啊？
而且c/cpp程序可以手工做这件事情。手工做的东西可能慢一点，但是也可以同样精致，甚至是最精致的，优化的逻辑是人设计，有可能不一定符合全部情况，但是人手工制作就可以抵达理论的完美程度。==========ref start
java在内在回收方面的速度也可以和C++一样快甚至更快。而且内存在摩尔定律下越来越便宜，也不再是java担心的了
==========ref end
除却早期内存资源昂贵外，效率也是一个重要问题，不然当年bs就不会在这个问题上浪费这么脑力和时间来思考了， 手工控制内存比自动内存回收效率是要高的。还有java的fans吹吹牛yy一下是可以的，但是不要太过分，这东西不利于身心健康。专业程序员的代码中，c的平均代码执行效率大约是asm的80% （似乎出自谭浩强的c）,
cpp的代码执行效率比c稍低。
java能超出c/cpp这么多倍真是让人惊讶,吹吧，反正吹牛又不犯法。
public static void main(String[] args) {
long i,j,x,z;
double y,tmp1;
i=System.currentTimeMillis();
String str;
for(z=0; z<3; z++)
{
for (x = 0; x < 10000000 ; x++)
{
str="ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789~!@#$%^&*()_+";
}
for(y = 0.0; y <10000000.0 ; y++)
{
tmp1 = y/3.1415926;
}
}
j = System.currentTimeMillis();
System.out.println(j-i);
}
}JAVA JDK6 667豪秒
DEV-C++ 4。9。9。0 4500豪秒 服了
#include <iostream>
#include <stdlib.h>
#include <windows.h>
using namespace std;int main(int argc, char *argv[])
{
long i,j,x,z;
double y,tmp1;
i=GetTickCount();
string str;
for(z=0; z<3; z++)
{
for (x = 0; x < 10000000 ; x++)
{
str="ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789~!@#$%^&*()_+";
}
for(y = 0.0; y <10000000.0 ; y++)
{
tmp1 = y/3.1415926;
}
}
j = GetTickCount();
printf("%d",j-i);
system("PAUSE");
return 0;
}
楼上的去试下嘛 我也不知道是不是真的，反正我是试过了 这代码可是一摸一样的哦 都是垃圾代码 用他试肯定没有问题
str="ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789~!@#$%^&*()_+";
这句在Java里,前后的类型是一样的,如果编译器够好的话,这句就等于没写.
但在C++里,这根本是两种东西,如果后面的字符串改成string常量,那就会快很多.如果所使用的STL中应用了写时复制技术,那这句开销基本为0.
而后面的浮点运算....是个优化编译器都要把它优化掉.....写程序关键在人........
JAVA里 str="ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789~!@#$%^&*()_+"; 只是把指针指向保存“ABCD。。”这个字符串的地址而已
C++里却是直接拷贝到str对象的地址里（Heap）了， 错了错了
虽然Java是我6年来的饭碗，但我对Java快过C++持保留意见
?
对于JAVA快还是C快，我不太清楚。
谢谢楼上几位前辈，尤其是
gmdroc() ( ) 信誉：100 Blog
狂摆事实，非常感谢！让我了解了很多知识。我听到的JAVA不如C快，只是在3D领域，但是具体怎么样，
我真的没有实验过。期待着JAVA在速度上全面超越C的那一天！
===========================================================
Java 3D目前已经和C＋＋一样是直接调用硬件加速，已经有许多用纯Java写3D 游戏。
http://www.chinaunix.net/jh/46/217418.html
?
我把 http://math.nist.gov/sci 的java和c代码下载下来测试了一下， java 和 c 的版本每个＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
你在运行java时有没有打开java的-server 选项？
以这个来说：
前两个图表中，java未打开-server选项，所以java输给了c++。而最后一个比赛中,java打开了-server选项，java就赢了c++
http://www.tommti-systems.de/go.html?http://www.tommti-systems.de/main-Dateien/reviews/languages/benchs.htmlhttp://www.tommti-systems.de/go.html?http://www.tommti-systems.de/main-Dateien/reviews/languages/benchs.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 concatC++ (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选项后，取得了大多数测试的冠军
以下不知道是谁写的代码。如果是CSDN上的人我就不说什么，不会写就不要写。==================================================public class SpeedTest {
public static void main(String[] args) {
long i,j,x,z;
double y,tmp1;
i=System.currentTimeMillis();
String str;
for(z=0; z<3; z++)
{
for (x = 0; x < 10000000 ; x++)
{
str="ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789~!@#$%^&*()_+";
}
for(y = 0.0; y <10000000.0 ; y++)
{
tmp1 = y/3.1415926;
}
}
j = System.currentTimeMillis();
System.out.println(j-i);}
}
#include <iostream>
#include <stdlib.h>
#include <windows.h>
using namespace std;int main(int argc, char *argv[])
{
long i,j,x,z;
double y,tmp1;
i=GetTickCount();
string str;
for(z=0; z<3; z++)
{
for (x = 0; x < 10000000 ; x++)
{
str="ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789~!@#$%^&*()_+";
}
for(y = 0.0; y <10000000.0 ; y++)
{
tmp1 = y/3.1415926;
}
}
j = GetTickCount();
printf("%d",j-i);
system("PAUSE");
return 0;
}
==================================================C++代码里面混用了C, C++, Windows API，还有“system("PAUSE")”，这么糟糕的风格也好意思拿出来。
std::string是这么用的吗？学过STL吗？知道什么是值语意吗？不多和你说没用的，只是简单改下运行：#include <iostream>
#include <stdlib.h>
#include <windows.h>
using namespace std;int main(int argc, char *argv[])
{
long i,j,x,z;
double y,tmp1;
i=GetTickCount();
const char* str;
for(z=0; z<3; z++)
{
for (x = 0; x < 10000000 ; x++)
{
str="ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789~!@#$%^&*()_+";
}
for(y = 0.0; y <10000000.0 ; y++)
{
tmp1 = y/3.1415926;
}
}
j = GetTickCount();
printf("%d",j-i);
return 0;
}
==================================================修改后在我的机器上（很老的机器）结果：Java [1.5.0_08] -> 721ms
C++ [MinGW] -> 221ms
C++ [BCC32] -> 470ms
C++ [vc7.1] -> 180ms把循环调得更高些差距会更明星。我承认C++快得很有限，但绝对不是所谓的比Java慢。Java可以做的很好，然而追求速度，胡乱鼓吹从来就不是一个合格的Java程序员所为。
?
有点像是说是找个翻译来翻译英语给你的速度快，还是你自己懂英语自己读的速度快，呵呵。
====================================
这个比喻不当。java可以进行动态优化,而c++不行。举个小例子：
大家都知道inline（内联）能让程序运行的更快，但C＋＋不可能在所有调用方法的地方都inline，但java可以，java可以在运行的时候发现某个方法被调用了许多次，java hotspot编译器就可以将这个方法内联成二进制代码(这可能花费了0.001秒)，如果一个方法被调用十万次，每次调用能省下0.0001秒，那么就省下了10秒。那么动态优化来进行内联所花费的0.001和省下的10秒非常划算？很明显，动态优化更加划算，java比c++更聪明
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
请打开java 的-server后再运行java
http://www.tommti-systems.de/go.html?http://www.tommti-systems.de/main-Dateien/reviews/languages/benchs.html请看第三个图表
===============
结论：14项Bench中，Java获胜9项，C＋＋5项
java以9：5战胜C++，而且其中很多项是以大比分领先：
Methord Call:近20倍
Object creation：4倍
Hash: 2倍半
word count:1倍半
Fibonacci：1倍半 这个证据中绝大多数java获胜的项都是用-server选项来取得的，也就是Server VM。
FFT (1024): 150.8336752366756
SOR (100x100): 387.8733963674583
Monte Carlo : 88.12720146546992
Sparse matmult (N=1000, nz=5000): 263.7263439793699
LU (100x100): 647.3842362848362java.vendor: Sun Microsystems Inc.
java.version: 1.6.0
os.arch: x86
os.name: Windows 2000
os.version: 5.0C:\Documents and Settings\Administrator\桌面\sci2_1c>java -cp sci2lib.jar -server jnt.sci2.commandlineSciMark 2.0aComposite Score: 306.78196897286034
FFT (1024): 151.67309913043476
SOR (100x100): 387.8733963674583
Monte Carlo : 88.12720146546992
Sparse matmult (N=1000, nz=5000): 263.7263439793699
LU (100x100): 642.5098039215686java.vendor: Sun Microsystems Inc.
java.version: 1.6.0
os.arch: x86
os.name: Windows 2000
os.version: 5.0C:\Documents and Settings\Administrator\桌面\sci2_1c>java -cp sci2lib.jar -server jnt.sci2.commandlineSciMark 2.0aComposite Score: 306.8051876391344
FFT (1024): 150.88587548285042
SOR (100x100): 390.38797784303205
Monte Carlo : 88.09828094822083
Sparse matmult (N=1000, nz=5000): 262.144
LU (100x100): 642.5098039215686java.vendor: Sun Microsystems Inc.
java.version: 1.6.0
os.arch: x86
os.name: Windows 2000
os.version: 5.0------------------------------------------------------------------ C的结果 (VC 2005 Release)C:\Documents and Settings\Administrator\桌面\sci2_1c\test\Release>test
** **
** SciMark2 Numeric Bench, see http://math.nist.gov/sci **
** for details. (Results can be submitted to [email protected]) **
** **
Using 2.00 seconds min time per kenel.
Composite Score: 331.41
FFT Mflops: 188.53 (N=1024)
SOR Mflops: 342.63 (100 x 100)
MonteCarlo: Mflops: 60.08
Sparse matmult Mflops: 383.14 (N=1000, nz=5000)
LU Mflops: 682.67 (M=100, N=100)C:\Documents and Settings\Administrator\桌面\sci2_1c\test\Release>test
** **
** SciMark2 Numeric Bench, see http://math.nist.gov/sci **
** for details. (Results can be submitted to [email protected]) **
** **
Using 2.00 seconds min time per kenel.
Composite Score: 325.71
FFT Mflops: 174.42 (N=1024)
SOR Mflops: 342.51 (100 x 100)
MonteCarlo: Mflops: 63.16
Sparse matmult Mflops: 371.20 (N=1000, nz=5000)
LU Mflops: 677.25 (M=100, N=100)C:\Documents and Settings\Administrator\桌面\sci2_1c\test\Release>test
** **
** SciMark2 Numeric Bench, see http://math.nist.gov/sci **
** for details. (Results can be submitted to [email protected]) **
** **
Using 2.00 seconds min time per kenel.
Composite Score: 325.78
FFT Mflops: 174.42 (N=1024)
SOR Mflops: 342.51 (100 x 100)
MonteCarlo: Mflops: 63.64
Sparse matmult Mflops: 376.10 (N=1000, nz=5000)
LU Mflops: 672.25 (M=100, N=100)差距缩小了很多， 不过总的来说还是C程序稍快
=====================================
你这只是计算了其中的一项，就如同奥运会几百个项目你只比了几项。你看我给出的证据中，都是比较了许多项才得出Java比C++快的结论的：浮点、整数、矩阵、数组、IO、异常、三角函数、循环、字符串等等许多方面的比较，java和C++互有胜负，但总体上java获胜项更多，所以才说java更快，而不是单说java的某个方面。而且，即使是比较某个单项方面，也是用了许多种评测程序来测量，多数评测程序证明java获胜，最终才说java获胜，而不是说用某个评测程序比较java获胜才说java获胜。比如：
http://www.idiom.com/~zilla/Computer/javaCbench.html
http://www.shudo.net/jit/perf/
http://www.javaworld.com/javaworld/jw-02-1998/jw-02-jperf_p.html
http://www.kano.net/javabench/data
http://www.tommti-systems.de/go.html?http://www.tommti-systems.de/main-Dateien/reviews/languages/benchs.html
http://cpp.student.utwente.nl/bench/就用你测量的结果来说,5项评测中，java获胜2项，C++获胜3项，综合来说，C++胜，但其它方面比如浮点、整数、矩阵、数组、IO、异常、三角函数、循环、字符串等等的评测结果呢？
Java:
FFT (1024): 150.88587548285042
SOR (100x100): 390.38797784303205
Monte Carlo : 88.09828094822083
Sparse matmult (N=1000, nz=5000): 262.144
LU (100x100): 642.5098039215686C++
FFT Mflops: 188.53 (N=1024)
SOR Mflops: 342.63 (100 x 100)
MonteCarlo: Mflops: 60.08
Sparse matmult Mflops: 383.14 (N=1000, nz=5000)
LU Mflops: 682.67 (M=100, N=100)
最起码你已经见识到java的实力了，Monte Carlo这一项java的性能竟是C++的88/60=147.7% ！Java比C++快了近50%！
而C++比java领先最多的是Sparse matmult这一项，C++的性能是Java的 383.14/262.144=146.2%
也就是说：Java最快的项比C++快47.7%,而C++最快的项只比java快46.2%。你还觉得java比C++慢吗？
可是坦率的讲，我还是觉得有点像商家夸大的广告词，有吸引观众眼球的嫌疑。我不懂这些硬件环境，但是我认为应该先制造一个公平、标准的运行环境和测试代码，这样才有可比性，才有说服力。
*******************任何一个非新手的C++程序员都会用profiler发现c++程序的所谓hotspot并进行有针对性的优化。反正说java数学计算比fortran还快，一般应用比c/c++快N倍(也就暗示比汇编还快）是很搞笑的。
#include <iostream>
#include <stdlib.h>
#include <windows.h>
using namespace std;int main(int argc, char *argv[])
{
long i,j,x,z;
double y,tmp1;
i=GetTickCount();
const char* str;
for(z=0; z<3; z++)
{
for (x = 0; x < 10000000 ; x++)
{
str="ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789~!@#$%^&*()_+";
}
for(y = 0.0; y <10000000.0 ; y++)
{
tmp1 = y/3.1415926;
}
}
j = GetTickCount();
printf("%d",j-i);
return 0;
}这段C代码也够烂的，一个高度优化的C++编译器会发现str="ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789~!@#$%^&*()_+"和tmp1 = y/3.1415926;两句在后面根本没有用到过，结果会跳过此二句。
java 永远不可能比c/c++快
我想当初也有人为汇编快还是C快争个不停吧
我想当初也有人为汇编快还是C快争个不停吧
我想当初也有人为汇编快还是C快争个不停吧
我想当初也有人为汇编快还是C快争个不停吧
我想当初也有人为汇编快还是C快争个不停吧
我想当初也有人为汇编快还是C快争个不停吧
我想当初也有人为汇编快还是C快争个不停吧
那假如用JAVA做一个虚拟机就会比JAVA更快.
我没做试验,但是每次打开做的JAVA桌面程序,只觉得比FLASH快.难道你们每天都不用普通的应用程序了吗?
for(i=0;i<1000000000; i++) a[i]=i;
for(i=0; i<1000000000-1; i++)
{
for(j=i+1; j<1000000000; j++)
{
if(a[i]<a[j])
{
t=a[i];
a[i]=a[j];
a[j]=t;
}
}}-------------
来这段吧 排序的 这个总会准吧
我的观点是：
1.Java速度的确快了很多，现在最优的Java运行时速度已经能赶上普通（注意是普通）C++的速度，不说快，但是能持平。
2.Java速度比不上优秀C++编译器、C和汇编的。另外楼上几位C++/C高手，有一个观点是错误的，语言速度比较时不能比较人为优化的程序，因为毕竟程序员水平有差别，这是人为的速度因素，不能算在内，要比就比语言平台（编译器、虚拟机）自身所做的优化，你拿一个C++高手写得优化程序，恐怕它要比虚拟机优化的结果效率高的多，但你想过没有，你这是C/C++程序员人和Java虚拟机比，这是很不公平的，现在计算机的水平最高也不可能超过一个人长时间通过经验、观察和研究得出的算法比啊。要比就应该去掉人为因素，比如大概模拟双方普通程序员能写出的水平。所以我说Java和普通C++的结果相当的，是指在统计概率下，非人工细致优化，取普通人水平写得代码的情况进行比较，仅靠语言平台进行优化，而不要任何认为因素的干扰情况下的结果。
我的观点是：
1.Java速度的确快了很多，现在最优的Java运行时速度已经能赶上普通（注意是普通）C++的速度，不说比它快，但是起码能持平。
2.Java速度比不上优秀C++编译器、C和汇编的。另外楼上几位C++/C高手，有一个观点是错误的，语言速度比较时不能比较人为优化的程序，因为毕竟程序员水平有差别，这是人为的速度因素，不能算在内，要比就比语言平台（编译器、虚拟机）自身所做的优化，你拿一个C++高手写得优化程序，恐怕它要比虚拟机优化的结果效率高的多，但你想过没有，你这是C/C++程序员人和Java虚拟机比，这是很不公平的，现在计算机的水平最高也不可能超过一个人长时间通过经验、观察和研究得出的算法比啊。要比就应该去掉人为因素，比如大概模拟双方普通程序员能写出的水平。所以我说Java和普通C++的结果相当的，是指在统计概率下，非人工细致优化，取普通人水平写得代码的情况进行比较，仅靠语言平台进行优化，而不要任何人为因素的干扰情况下的结果。
?
按照上面很多人的意思是说一个计算机模拟另外一个计算机就会更快,
那假如用JAVA做一个虚拟机就会比JAVA更快.
我没做试验,但是每次打开做的JAVA桌面程序,只觉得比FLASH快.难道你们每天都不用普通的应用程序了吗?
============================================================
你说搞清楚，你“启动”程序时，你比的实际是“启动速度”，而不是“运行速度”。java要先启动JVM再开始运行程序。java的速度实际上分为几个部分：
1：启动速度
2：将Java字节码编译成二进制机器指定所需要的编译时间，这个编译器可以是JIT，也可以是HotSpot，或是最古老的解释器。
3：运行速度
4：内存回收速度。在比较Server端程序时，1和2其实是忽略不计的。在比较客户端程序时，我承认在1上，java目前是比不过c++的，至少java要先启动jvm。但将来有一天也许JVM和操作系统一同启动，这样java 启动速度问题也可以解决。但有一点要说明，C++启动之所以快，有很大部分原因是C++程序运行时需要的许多.exe或.dll之类的文件在操作系统启动时或其它程序启动时局装入内存或已经启动了在4方面，前面我提到了一篇文章《很难相信Java居然能和C++一样快，甚至还能更快一些》，这就是讲java在内在回收方面的速度也可以和C++一样快甚至更快。而且内存在摩尔定律下越来越便宜，也不再是java担心的了单就3来说，由于java可以根据运行时的情况进行优化，java已经整体上超过了C++。如果你仔细看过前面我给你的证据的话你就会是不同的结论了
?
不要比了,同样算法的代码不会比c++快.除非能吧java编译成,exe,不过gcj也是将来的希望
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
不比怎么知道谁更快？要知道，Java在运行时刻就是被JVM中的JIT编译器或HotSpot编译器编译成二进制的指令序列，这其实就是一种'内存中的exe'文件。所谓gcj就是和c++一样的“预编译”，也就是在程序运行时编译，而JVM进行的是“动态编译”，也就是程序运行过程中进行编译，只要编译优化花费的成本比优化后节省的时间小，那么“动态编译”的性能就会高于“预编译”，也就是说JVM快过C++编译器。而事实已经证明，Java编译优化花费的成本比优化后节省的时间小，Java编译器编译出来的“内存中的exe”比C++编译器的“预编译”编译出来的“存在硬盘上的exe”更优化，Java更快。因为Java可以根据运行时的状态进行编译。不懂的人可以去看看有关Java HotSpot(TM) 编译器的相关文章
?
毕竟大部分程序员都是普通人，不可能人人都优化出那么高的效率，而且在大型应用程序开发时，考虑到可维护性、可移植性、可扩展性、容错性以及软件开发效率等软件工程质量因素，不允许把程序进行过多得优化。语言毕竟不是科学研究工具，不是大家玩的玩具，而是商业赚钱工具，在这种情况，考虑普通程序员的开发水平尤为重要。所以说人为程序优化不能算做语言平台的速度，应该考虑普通程序员的水平，取平均值。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
你说的很正确，一个学过一年的java程序员和一个学过一年的C++程序员同时开发同样的程序，由于JVM做了绝大多数优化，java程序员可以很容易就写出高性能的程序；而C++程序员要人为进行许多优化，要么C++程序员要花费大量的时间进行人工优化从而减低开发效率，要么开发出来的程序未经过全面的优化使得效率低下。我前面已经说过了，“比速度的实质”就是在比Java编译器和C++编译器谁能编译出更加优化的“二进制指令序列”，明显，Java获胜！
**************这是比较荒唐的一种比法， 两种语言都不是一年能真正学好的，开发程序也不是干一年就不干了的，两者能开发的程序的范围也不一样
#include <stdlib.h>
#include <time.h>
long sum=0,upperlim=1;
void test(long row, long ld, long rd){
if (row != upperlim){
long pos = upperlim & ~(row | ld | rd);
while (pos){
long p = pos& -pos;
pos -= p;
test(row+p, (ld+p)<<1, (rd+p)>>1);
}}
else
sum++;
} int main(int argc, char *argv[])
{
time_t tm;
int n=8;
if(argc!=1)n=atoi(argv[1]);
tm=time(0);
if((n<1)||(n>32)){
printf(" heh..I can't calculate that.\n");
exit(-1);}
printf("%d Queens\n",n);
upperlim=(upperlim<<n)-1;
test(0,0,0);
printf("Number of solutions is %ld, %d seconds\n", sum,(int)(time(0)-tm));
}在2.3G的P4上运行结果是:E:\USBTEST\mycode>eightqueen
8 Queens
Number of solutions is 92, 0 secondsE:\USBTEST\mycode>eightqueen 10
10 Queens
Number of solutions is 724, 0 secondsE:\USBTEST\mycode>eightqueen 12
12 Queens
Number of solutions is 14200, 0 secondsE:\USBTEST\mycode>eightqueen 15
15 Queens
Number of solutions is 2279184, 4 secondsE:\USBTEST\mycode>eightqueen 16
16 Queens
Number of solutions is 14772512, 29 seconds就是求16皇后的14772512种解只要29秒钟。哪位不服气可以用java写一下，看能不能达到C语言1/5的速度。
但是估计这也是8皇后问题中最牛的一种算法了吧?(很有可能是楼上收集的,并非自己写的代码)以上纯属猜测,莫见怪!希望java高手能搞出更牛的算法~~呵呵
public class Queen
{
static int sum = 0, upperlim = 1; private static void test(int row, int ld, int rd)
{ if (row != upperlim) {
int pos = upperlim & ~(row | ld | rd);
while (pos != 0) {
int p = pos & -pos;
pos -= p;
test(row + p, (ld + p) << 1, (rd + p) >> 1);
}
}
else
sum++;
} public static void main(String[] args)
{
int n = 8; if (args.length == 1)
n = Integer.parseInt(args[0]); long tm = System.currentTimeMillis();
if ((n < 1) || (n > 32)) {
System.out.println(" heh..I can't calculate that.");
System.exit(-1);
}
System.out.println(n + " Queens");
upperlim = (upperlim << n) - 1; test(0, 0, 0);
System.out.println("Number of solutions is " + sum + ", " + (System.currentTimeMillis() - tm) + " milliseconds");
}
}------------------------------------- C++ 的结果 (VC 2003 Release)C:\Documents and Settings\xxxxxxxx\桌面\queen\Release>queen 16
16 Queens
Number of solutions is 14772512, 21 secondsC:\Documents and Settings\xxxxxxxx\桌面\queen\Release>queen 16
16 Queens
Number of solutions is 14772512, 21 secondsC:\Documents and Settings\xxxxxxxx\桌面\queen\Release>queen 16
16 Queens
Number of solutions is 14772512, 21 seconds
------------------------------------------- Java的结果 (java 1.6 -server)C:\Documents and Settings\xxxxxxxx\桌面\queen>java Queen 16
16 Queens
Number of solutions is 14772512, 24358 millisecondsC:\Documents and Settings\xxxxxxxx\桌面\queen>java Queen 16
16 Queens
Number of solutions is 14772512, 24139 millisecondsC:\Documents and Settings\xxxxxxxx\桌面\queen>java Queen 16
16 Queens
Number of solutions is 14772512, 24139 milliseconds
16 Queens
Number of solutions is 14772512, 28748 millisecondsC:\Documents and Settings\xxxxxxxx\桌面\queen>java -server Queen 16
16 Queens
Number of solutions is 14772512, 28717 millisecondsC:\Documents and Settings\xxxxxxxx\桌面\queen>java -server Queen 16
16 Queens
Number of solutions is 14772512, 28795 milliseconds
用C++优化是靠程序员的,这对程序员的要求高,而且工作量大,后期难维护等,但是一个高级C++程序员可以写出针对某一特定平台的比JAVA效率高很多的代码;在今天硬件还不是很好,对速度有特别高要求的地方,C++开发更好;
如果未来一天硬件速度不成问题的话,JAVA或许可以取代C++
?
一个学过一年的java程序员和一个学过一年的C++程序员同时开发同样的程序
**************这是比较荒唐的一种比法， 两种语言都不是一年能真正学好的，开发程序也不是干一年就不干了的，两者能开发的程序的范围也不一样
===========================================
你才比较荒唐。我当然指的是平均状态，比如1000个一年的javaer和1000个一年的Cpper的平均值。用1000个5年的javaer和1000个5年的Cpper的平均值来比较，还是一样的结果
回复人：gtlang78() ( 两星(中级)) 信誉：100 2006-12-27 12:32:31 得分:0
?
呵呵，让我来测吧，把 hai1039 兄的C++ 代码翻译成了java代码， 最后结果是 C++程序21秒，java程序是24秒， 虽然没有C++的快，但是显然远远超过了1/5
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
这只是一个项目，我前面给出的证据中，都是浮点、整数、矩阵、数组、IO、异常、三角函数、循环、字符串等等许多方面的比较，java和C++互有胜负，但总体上java获胜项更多，所以才说 java更快，而不是单说java的某个方面。而且，即使是比较某个单项方面，也是用了许多种评测程序来测量，多数评测程序证明java获胜，最终才说 java获胜，而不是说用某个评测程序比较java获胜才说java获胜。
?
另外，java程序有个特点，运算越久，优化的越好，也就是说，一个java程序运算了几分钟后，性能可能要比刚开始时快几倍！这一点也是java虚拟机特有了，因为运行的越久，分支预测就越准确，在程序运行的一个循环正在运行时，JVM就可以先“预测”一个最可能的分支，将这部分指令提前读入CPU，而c++是无法做到这一点的。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
再来一个证据支持上面的观点：http://www.tempest-sw.com/bench/
由于这个证据中使用的是十分古老、性能低下的JDK版本，所以不代表java现在的速度（我也承认过去java确实很慢，但最新的JDK非常的快）http://www.tempest-sw.com/bench/ 这个证据是计算圆周率，最后一个表格中，可以看到，当计算5位小数时，JDK 1.3.1花的时间(1.523秒)是C 2的时间(0.100秒)的15倍，但在计算20000位小数时，JDK 1.3.1花的时间(224.293秒)是C 2的时间(132.240秒)的1.69倍，可见java是运算越久性能越高的。
?
不过这里好象讲的是运行速度，，不知道启动速度，怎样？
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
java的速度实际上分为几个部分：
1：启动速度
2：将Java字节码编译成二进制机器指定所需要的编译时间，这个编译器可以是JIT，也可以是HotSpot，或是最古老的解释器。
3：运行速度
4：内存回收速度。在比较Server端程序时，1和2其实是忽略不计的。在比较客户端程序时，我承认在1上，java目前是比不过c++的，至少java要先启动jvm。但将来有一天也许JVM和操作系统一同启动，这样java 启动速度问题也可以解决。但有一点要说明，C++启动之所以快，有很大部分原因是C++程序运行时需要的许多.exe或.dll之类的文件在操作系统启动时或其它程序启动时已经装入内存或已经启动了在4方面，前面我提到了一篇文章《很难相信Java居然能和C++一样快，甚至还能更快一些》，这就是讲java在内在回收方面的速度也可以和C++一样快甚至更快。而且内存在摩尔定律下越来越便宜，也不再是java担心的了而我单就3来说，由于java可以根据运行时的情况进行优化，java已经整体上超过了C++。
当然Java肯定还是没有超过C++，更不用说C。
C/C++高手也不要再否认这个事实了。
Java能取得这样的成就毕竟不容易，想当初Java是以解释型语言的身份出现。
1.Java速度与普通C++的速度持平。
2.Java速度比不上优秀C++/C的速度。
?
总之关于两种语言的速度，我的观点就是：
1.Java速度与普通C++的速度持平。
2.Java速度比不上优秀C++/C的速度。
=========================================
我想请你定义一下何谓“优秀C++/C的速度”，你是说不用C++编译器来优化而用C++程序员来优化吗？如果是这样，你为什么不直接写010101011100001的二进制指令呢？我们之所以要用C++编译器和Java编译器来优化，就是为了不需要人来进行优化，这才是比较的真正意义：“比速度的实质”就是在比Java编译器和C++编译器谁能编译出更加优化的“二进制指令序列”，明显，Java编译器获胜！如果你定义的“优秀C++/C的速度”是指“优秀C++/C程序员手工优化后的速度”，那么你顶多说的是“优秀C++/C程序员胜过目前的Java编译器”。要知道，事实上，所有程序员能对程序做的优化，理论都能用编译器来优化，只是有的编译器还没有实现这些优化措施。这十年来大家所看到的"JVM的速度不断提升"的实质，就是科学家们不断把各种程序员能做的优化措施加入到JVM中的编译器里，使得JVM能做越来越多的优化，使得Java HotSpot编译器能做的优化比C++的编译器做的优化更多更好，这样Java的速度也就超过了C++
你咋不开窍呢，如果你继续说Java的速度超过C++，会有越多的C/C++高手不服，咋就不能让一让呢:)
Time=37
0314159265358979323846264338327950288419716939937510......C:\Documents and Settings\xxxxxxx\桌面\pi\pi_c\Release>pi_c 20000
Time=37
0314159265358979323846264338327950288419716939937510......C:\Documents and Settings\xxxxxxx\桌面\pi\pi_c\Release>pi_c 20000
Time=37
0314159265358979323846264338327950288419716939937510......(Java 1.6 -server 单位:毫秒) -----------------------------------------C:\Documents and Settings\xxxxxxx\桌面\pi>java -server Pi 20000
Time=39935
0314159265358979323846264338327950288419716939937510......C:\Documents and Settings\xxxxxxx\桌面\pi>java -server Pi 20000
Time=39997
0314159265358979323846264338327950288419716939937510......C:\Documents and Settings\xxxxxxx\桌面\pi>java -server Pi 20000
Time=40044
0314159265358979323846264338327950288419716939937510......
**********************同样也可以在C++的编译选项里微调. 比如把上面八皇后的程序源码不变，在BCB6.0编译选项里微调一下register变量，字节对齐，N=16的执行时间从29秒变成25秒，加快了15%.没有什么道理java在动态时能做的cpu指令优化，好的c++编译器在静态时不能做，连DOS时代的程序都可以针对不同CPU执行不同指令。
hai1039(天下)在2.3G的P4上运行的,
俺刚才用 gtlang78() 的java程序在
c4 2.8 512M内存的机器上试了一把,
不用-server 在27-28秒,不到29秒;用了-server在23秒多.
不想参与争论,只是好奇试了下,顺便又学到东西了.