之前常听说C#和Java与C++的速度接近,更有甚者说很多情况下他们都比C++快,而且举出一大堆的范例(多是些IO操作,测量误差超级大,因此很难令人信服),于是听到很多人出来圆场,说对于语言内建类型(整形、浮点型等),编译成二进制应该相差不大,这似乎有些道理,但我仍然有些怀疑。
还曾经听不少人鼓吹过脚本,说脚本程序比C++程序慢不了多少,有人甚至给10%,对此我不加评论了,看看这里的测试结果就一目了然。
下面有个浮点密集型的计算程序,没有使用blitz++和MTL,很符合一般性应用,如果用上他们那就不好说怎么样,因为主要是和Fortran比科学计算速度时才用。已经有人编码测试了。
只讲速度,如果再比内存,其他几种语言就没有必要比下去了。
不同语言版本的代码到原作者提供的地址去下载:http://files.cnblogs.com/miloyip/smallpt20100623.zip
下面是测试用的系统配置:
测试配置
- 硬件: Intel Core i7 920@2.67Ghz(4 core, HyperThread), 12GB RAM
- 操作系统: Microsoft Windows 7 64-bit
测试名称
|
编译器/解译器
|
编译/运行选项
|
VC++
|
Visual C++ 2008 (32-bit)
|
/Ox /Ob2 /Oi /Ot /GL /FD
/MD /GS- /Gy /arch:SSE /fp:fast
|
VC++_OpenMP
|
Visual C++ 2008 (32-bit)
|
/Ox /Ob2 /Oi /Ot /GL /FD
/MD /GS- /Gy /arch:SSE /fp:fast /openmp
|
IC++
|
Intel C++ Compiler (32-bit)
|
/Ox /Og /Ob2 /Oi /Ot /Qipo
/GA /MD /GS- /Gy /arch:SSE2 /fp:fast /Zi /QxHost
|
IC++_OpenMP
|
Intel C++ Compiler (32-bit)
|
/Ox /Og /Ob2 /Oi /Ot /Qipo
/GA /MD /GS- /Gy /arch:SSE2 /fp:fast /Zi /QxHost /Qopenmp
|
GCC
|
GCC 4.3.4
in Cygwin (32-bit)
|
-O3 -march=native
-ffast-math
|
GCC_OpenMP
|
GCC 4.3.4
in Cygwin (32-bit)
|
-O3 -march=native
-ffast-math -fopenmp
|
C++/CLI
|
Visual C++ 2008 (32-bit),
.Net Framework 3.5
|
/Ox /Ob2 /Oi /Ot /GL /FD
/MD /GS- /fp:fast /Zi /clr /TP
|
C++/CLI_OpenMP
|
Visual C++ 2008 (32-bit),
.Net Framework 3.5
|
/Ox /Ob2 /Oi /Ot /GL /FD
/MD /GS- /fp:fast /Zi /clr /TP /openmp
|
C#
|
Visual C# 2008 (32-bit),
.Net Framework 3.5
|
|
*C#_outref
|
Visual C# 2008 (32-bit),
.Net Framework 3.5
|
|
F#
|
F# 2.0 (32-bit), .Net Framework 3.5
|
|
Java
|
Java SE 1.6.0_17
|
-server
|
JsChrome
|
Chrome 5.0.375.86
|
|
JsFirefox
|
Firefox 3.6
|
|
LuaJIT
|
LuaJIT 2.0.0-beta4
(32-bit)
|
|
Lua
|
LuaJIT (32-bit)
|
-joff
|
Python
|
Python 3.1.2
(32-bit)
|
|
*IronPython
|
IronPython 2.6 for .Net 4
|
|
*Jython
|
Jython 2.5.1
|
|
Ruby
|
Ruby 1.9.1p378
|
|
渲染的解像度为256x256,每象素作100次采样。
结果及分析
下表中预设的相对时间以最快的单线程测试(IC++)作基准,用鼠标按列可改变基准。由于Ruby运行时间太长,只每象素作4次采样,把时间乘上25。另 外,因为各测试的渲染时间相差很远,所以用了两个棒形图去显示数据,分别显示时间少于4000秒和少于60秒的测试(Ruby是4000秒以外,不予显 示)。
Test
|
Time(sec)
|
Relative time
|
IC++_OpenMP
|
2.861
|
0.19x
|
VC++_OpenMP
|
3.140
|
0.21x
|
GCC_OpenMP
|
3.359
|
0.23x
|
C++/CLI_OpenMP
|
5.147
|
0.35x
|
IC++
|
14.761
|
1.00x
|
VC++
|
17.632
|
1.19x
|
GCC
|
19.500
|
1.32x
|
C++/CLI
|
27.634
|
1.87x
|
Java
|
30.527
|
2.07x
|
C#_outref
|
44.220
|
3.00x
|
F#
|
47.172
|
3.20x
|
C#
|
48.194
|
3.26x
|
JsChrome
|
237.880
|
16.12x
|
LuaJIT
|
829.777
|
56.21x
|
Lua
|
1,227.656
|
83.17x
|
IronPython
|
2,921.573
|
197.93x
|
JsFirefox
|
3,588.778
|
243.13x
|
Python
|
3,920.556
|
265.60x
|
Jython
|
6,211.550
|
420.81x
|
Ruby
|
77,859.653
|
5,274.69x
|
C++/.Net/Java组别
静态语言和动态语言在此测试下的性能不在同一数量级。先比较静态语言。
C++和.Net的测试结果和上一篇博文相若,而C#和F#无显著区别。但是,C++/CLI虽然同样产生IL,于括管的.Net平台上执行,其渲染时间
却只是C#/F#的55%左右。为什么呢?使用ildasm去反汇编C++/CLI和C#的可执行文件后,可以发现,程序的热点函数
Sphere.Intersect()在两个版本中,C++/CLI版本的代码大小(code size)为201字节, C#则为125字节! C++/CLI版本在编译时,已把函数内所有Vec类的方法调用全部内联,而C#版本则使用callvirt调用Vec的方法。估计JIT没有把这函数进 行内联,做成这个性能差异。另外,C++/CLI版本使用了值类型,并使用指针(代码中为引用)托管代码(C++/CLI)的渲染时间,仅为原生非括管代码(IC++)的1.91倍,个人觉得.Net的JIT已经非常不错。
另一方面,Java的性能表现非常突出,只比C++/CLI稍慢一点,Java版本的渲染时间为C#/F#的65%左右。以前一直认为,C#不少设计会使其性能高于Java,例如C#的方法预设为非虚,Java则预设为虚;又例如C#支持struct作值类型(value type),Java则只有class引用类型(reference type),后者必须使用GC。但是,这个测试显示,Java VM应该在JIT中做了大量优化,估计也应用了内联,才能使其性能逼近C++/CLI。
纯C++方面,Intel C++编译器最快,Visual C++慢一点点(1.19x),GCC再慢一点点(1.32x)。这结果符合本人预期。 Intel C++的OpenMP版本和单线程比较,达5.16加速比(speedup),对于4核Hyper Threading来说算是不错的结果。读者若有兴趣,也可以自行测试C# 4.0的并行新特性。
动态语言组别
首先,要说一句,Google太强了,难以想像JsChome的渲染时间仅是IC++的16.12倍,C#的4.94倍。
以下比较各动态语言的相对时间,以JsChrome为基准。 Chrome的V8 JavaScript引擎(1.00x)大幅抛离Firefox的SpiderMonkey引擎(15.09x)。而LuaJIT(3.49x)和Lua(5.16x)则排第二和第三名。 Lua的JIT版本是没有JIT的68%,并没有想像中的快,但是也比Python(16.48x)快得多。曾听说过Ruby有效能问题,没想到问题竟然如此严重(327.31x),其渲染时间差不多是Python的20倍.