掺和比试

Milo老师搞了一个语言大比试——《C++/C#/F#/Java/JS/Lua/Python/Ruby渲染比试》。我觉得挺好玩的，本来早就想掺和，只是最近比较忙，现在真是来晚了。

不过也没什么能掺和的，因为Milo老师的比试已经很全面了，我也就是提供一点自己的测试数据罢了。

硬件：Intel Q8200 2.33G/4G RAM

软件：Windows 2003 Server

说明：为便于与Milo老师的结论作参照，我这里以GCC版本为基准计算对比系数，其中括号内为換算到Milo老师环境中的相对比值。

VC学习版不提供OpenMP支持，GCC 4.2以前的版本也不支持，BCC更不用说，故OpenMP只试了Cygwin。

增 加了一列内存使用情况。基本上C++都差不多，Java则明显多得多。因为这个程序中涉及大量（数以十亿计）的小object的创建和删 除，JAVA的GC回收内存有一定的滞后性，所以运行时内存占用得会多一点，当然这也有个好处就是节约了不断回收小内存所花费的时间，对速度有一定的帮 助。

从结果上看新版本的C++编译器对于代码的优化还是很明显的，同样是GCC，Cygwin的4.3.4就比MinGW的3.4.5好得多——当然BCC是个例外，最新版本的速度也没有超过JAVA。

在研究过这个程序的代码以后发现，这个程序对内存管理的要求还是挺高的，对于有GC的VM语言或动态语言来说，实现起来会比较方便，C++的栈对象用起来也还不错（运算符重载更是方便），不过要是用C或DELPHI之类内存需要自己管理的语言就杯具了——如表上所示。

关于DELPHI版的说明：

因 为这个程序在运行时累计需要创建释放的对象多达15亿，而DELPHI的内存管理有个问题就是缺少自动释放的机制。虽然通过接口的引用计数机制是可以实现 类似的功能，但是需要增加很多不必要的函数调用，这样一来速度反而会大幅下降。现在采用的方式是手工即时释放。可能是因为DELPHI7的堆管理机制不是 很适合这种大量小对象的反复创建释放，运行一会以后速度就慢下来，以致于最后耗时很长。

后来我试着自己做了一个对象管理，以POOL的方式 进行管理，速度上略有提高，不过还是不明显。而FreePascal Compiler（FPC）显然有一些额外的优化，速度比我自己管理要快近一倍。但是Delphi 2010的优化更多，比FPC还要快约50%。不过从目标代码上看，D7只有100K，FPC是150K，D2010则是300K，看来后二者可能使用了 大量的INLINE优化——这种优化对这个应用来说很重要。

根据POOL反馈的数据显示，Vec对象累计创建：1565329629个，但实际峰值使用量（递归最深的时候）仅：1770个。

另外，可以注意到的是，我这里有两个版本是与Milo老师的相同：一个是Cygwin版，一个是JAVA版。其中非OpenMP的Cygwin版比Milo老师慢得很少，但是JAVA版却慢了很多。可见硬件性能的提升对于JAVA程序的帮助比较明显。