从静态页面的测试结果中可以看出，针对龙芯2F、o32与MIPS1编译的两组环境成绩近乎一致，而针对龙芯2F、n64模式编译的环境性能高出一筹，说明前两者的瓶颈在于o32这种ABI而非内核或编译Apache时指定的指令集。当测试用例转向复杂的动态页面，所有平台都无法突破11/9/43这一成绩，也许这就是处理器的极限？我们测试过的龙芯2F开发板配备了与福珑2F-6003相同的处理器和频率高出13%的内存，结果也只是静态页面处理能力得到小幅提高。 比起桌面应用，LAMP服务环境相对复杂的多，与内核的关联也更加紧密。这部分我们进行的颇为周折，起初因为各系统环境的内核抢占模式不统一，导致测试结果没有可比性，只能全部复测。不过，这也是第一次通过测试验证了内核几种抢占模式下的特征差异，为选择提供了依据。  做网络应用时，使用Server参数编译的内核状态最为稳定，可以准确找到系统的最大新建事务数，再此基础上哪怕多一个连接请求都会导致访问失败，并且多次测试的复现率可以达到100%。使用Desktop参数编译的内核稳定性稍差，只能将最大新建事务数锁定在一个比较小的范围，且很难通过复测找到一个准确值。我们在这种内核搭配针对龙芯2F、n64模式编译的LAMP环境下，只能将静态页面的新建能力锁定在1200/1180±50这一区域。而使用Low-Latency Desktop参数编译的内核，在搭配针对龙芯2F、o32模式编译的LAMP环境下只能稳定取得一个1100/1050的成绩。如再增加连接请求，非但每一次测试结果都不相同，成功访问事物的响应时间也会出现较大抖动。看来，支持抢占模式的内核虽然大大提升了图形界面下操作的响应时间，却不太适合做网络应用。尤其像静态页面这种Web服务，事物模型简单却为数众多，负载高时抢占内核执行的空隙效果不大，还会带来不小的系统开销。另外，根据复测得到的结果，内核抢占模式的设定对之前在命令行下进行的单任务测试几乎没有影响。 因为本次测试缺少n32模式的系统环境（针对龙芯2F、n32模式编译的LAME采用静态连接），导致不能确定龙芯平台上最适合实际应用的编译参数，这一点殊为可惜。就目前情况看，我们选择的应用软件都或多或少地从针对龙芯2F处理器的编译中获益。依照惯例，GCC的版本由测试版变为正式版后，编译优化的性能还会有小幅提高，将在几个月内发布的GCC 4.4正式版值得重点关注。 网络应用与桌面应用往往在运算模型方面相差甚大，受ABI的影响自然也不相同。n64模式在网络应用和o32模式在桌面应用方面的表现值得肯定，但它们占据优势的应用又是彼此的弱势领域。相信每个人都会想到，如果能集合o32与n64的优势就好了。确实，我们也这样想，于是就对兼具n64与o32特性的n32模式又多了那么几分期待。 |
