实际应用测试 接下来进行的实际应用性能测试相信更让人感兴趣。根据现有测试条件，我们选取了一些比较常见的应用作为测试项目，并将它们归纳为桌面与网络两大类。桌面部分包括病毒检测、压缩打包和音频编码三种应用，考量指标是完成任务需要的时间；网络部分则通过在不同系统环境下构建完整的LAMP（Linux/Apache/MySQL/PHP）服务，使用思博伦通信的Avalanche 2500应用层性能测试仪考察不同测试用例的每秒最大新建事务数。  病毒检测软件选用的是比较著名的ClamAV，引擎与特征库统一为测试当天的最新版本。测试用例是一个保存Windows系统下绿色软件的文件夹，内含52个子文件夹，共816个文件，大小为121MB。为加大负载，我们还将此文件夹在Windows下用WinRAR压缩为61.4MB大小的Zip格式文件，执行病毒检测时多了动态解压缩的步骤。从测试结果可以看出，针对龙芯2F、o32模式编译的代码与针对MIPS1指令集架构编译的代码执行效率相仿，后者的综合成绩还略好些；n64模式下的病毒检测速度相对较慢，看来ClamAV涉及到的计算模型并不能从纯64位环境中获益。 压缩打包测试直接利用了上面的测试用例。我们在bash下通过tar调用gzip，将文件夹打包成一个文件，并记录任务完成所用的时间。在这一环节，64位环境同样没有给应用带来性能提升。针对龙芯2F、o32模式编译的代码执行速度最快，领先MIPS1编译版本十几个百分点，应当是指令集与指令调度方面的原因。 音频编码的性能差异是实验室工程师最感兴趣的地方。根据以往的测试经验，这也是最能体现架构与指令集进步的部分。除了运算单元的改进，SIMD指令也有可能显著提高编码性能，但这一切都要通过优秀的编译器和适当的算法（代码）联合实现。本次测试我们采用的是著名的MP3编码软件LAME，目标对象是一个131MB大小、16位/44.1KHz的WAV文件，编码参数均为默认设置。可以看到，GCC 4.4针对龙芯2F的编译优化首次起到决定性的作用，即便最慢的o32模式的执行速度也比针对MIPS1指令集机构编译的代码快近50%。为弄清性能提升的主要原因，我们特别编译了一个版本进行对比：针对R4600处理器、n32模式编译的LAME完成编码工作共耗时252秒，看来性能提升的主要原因是使用了MIPS3指令集；而与龙芯2F、n32模式下超过1/10的性能差异，则可能源于不同的指令调度模型和SIMD指令。通过这项测试，我们推断音、视频编解码软件是最值得通过编译优化的一类程序，它们的性能很可能从GCC 4.4中得到质的提升。  为保持评估标准的一致性，我们在网络应用性能测试中沿用了先前的测试方法与测试用例。从结果来看，64位系统环境终于带来了性能提升，各项测试成绩均为第一。针对MIPS1指令集架构编译的LAMP环境表现也令人惊讶，在涉及动态页面解析的测试项中达到了与龙芯2F、n64模式相同的性能。同样是o32，针对龙芯2F编译的LAMP环境则有些令人失望，其表现出来的性能在本次测试中垫底。 |
