编译路漫漫

这是4月份的新闻的评论，一直没有时间来写，拖了两个月了。

四月份的时候，类似“龙芯性能不到iPhone6 A8性能的1/10？”的新闻[1][2][3]又一次把龙芯拉出来被人吐槽。其中出现 1/10 对比的一项是 SunSpider 测试，SPEC CINT2000 的测试差异没有那么大。另外没有贴出来 SPEC CFP2000 的分数对比。

作为一度天天跑SPEC和SunSpider等Benchmark的人来说，新闻中的测试报告是没有可信度的。性能测评需要有一套完整的流程，才能够确认自己获得的测评分数是正确的。不同的环境设定、软硬件组合、是否联网[7]等都会影响到SPEC的测评分数。

[4]中有人提供了反面的数据，表达另一种可能性。

就我个人的经验而言，龙芯的 SunSpider 性能差异更多的应该是在软件层面。现代的浏览器都通过（多个层级的）JIT来对JavaScript进行加速，开启和关闭JIT的SunSpider、Kraken、Octane 跑分差异可能会相差20～30倍。使用 iPhone 的同学可以在 Safari 和微信自带的浏览器中测试对比下速度差异（iOS 中只有 Safari 可以开 JIT）。三大开源浏览器JIT引擎对于龙芯采用的MIPS后端的支持都还很初级，甚至还不能正常使用。龙芯官方[6]和开源爱好者[5]的数据也印证了龙芯CPU跑 JavaScript 的尴尬。软件层面的缺失，或者往大了说，生态环境的问题，也是龙芯（MIPS架构）需要面对的一个大问题。

[1] http://www.leiphone.com/news/201504/aCIGktK8BJgon9BV.html

[2] http://tech.163.com/15/0406/14/AMHCJ04K000915BD.html

[3] http://tech.sina.com.cn/zl/post/detail/it/2015-04-09/pid_8476155.htm

[4] http://tieba.baidu.com/p/3684400301

[5] http://www.lingcc.com/2010/06/28/10983/

[6] http://www.loongson.cn/dev/ftp/doc/07FAQ/%E9%BE%99%E8%8A%AFFAQ_V0.8.pdf

[7] 我有一次跑SPEC的时候没有拔掉网线，结果内网MDNS广播风暴导致性能掉了非常多，内核处理TCP/IP需要跟Benchmark抢占资源。

这篇博客是对Mozilla这篇文章的简短编译，有兴趣的读者可以看原文。（PS：现在SpiderMonkey的架构越来越像是V8了。）

本周（2013-4-5）我们终于将 baseline 编译器加入了主分支，进入了 Firefox Nightly 版本。从开始开发到今天差不多半年的时间。

Baseline Compiler 是什么？

可以将 Baseline 编译器看成是 IonMonkey 的一个预备编译器（warm-up）。它的诞生使得我们在未来丢弃 JaegerMonkey 成为可能，也因此使得我们有机会大幅度的减少内存占用（在移除了JaegerMonkey之后）。这还使得我们实现新的语言特性、实现新的优化变得更加容易和直观。

引入了 Baseline 编译器之后我们的 SpiderMonkey 在各个 benchmark 上的性能提高了 5%～10%。你们可以在我们的自动性能评测网站上看到结果

为什么又要做一个JIT？

目前 Firefox 有 JaegerMonkey 和 IonMonkey 两个 JIT（这还不算已经移除的 TraceMonkey）。JaegerMonkey能够生成“很快的”代码，而IonMonkey能够生成“真正快的”代码。如果一段代码运行次数频繁，就使用JaegerMonkey编译它；如果之后运行还是很频繁，那就用IonMonkey再去编译一次。这样能够让重量级的优化用在真正需要的地方。但是这种策略的成功，需要仔细的权衡不同优化界别中编译优化的选择，因为编译本身也是需要耗费大量时间的，重量级的优化尤其如此。

简单来说，JaegerMonkey目前被我们当作简单快速的JIT来使用，但是它的设计初衷并不是这个。而 IonMonkey 跟 JaegerMonkey 之间的协作也存在一些问题。最好的解决方式是设计一个跟IonMonkey设计很接近的快速JIT，而baseline就是为了这个目的设计的。

SpiderMonkey的现状

JavaScript代码在SpiderMonkey中的解析过程大致如下：

1. JavaScript代码首先被解释器解释执行。解释器很慢，但是它可以保证较快的启动速度，并且可以为JIT收集类型信息。
2. 当一个函数变得“hot”（执行频率达到一定阈值），则调用JaegerMonkey进行JIT，JaegerMonkey使用解释器收集的类型信息来进行优化。
3. 当函数已经被JaegerMonkey编译，并且执行次数达到IonMonkey的编译阈值（“really hot”），IonMonkey启动，花费比JaegerMonkey多得多的时间生成比JaegerMonkey好得多的代码。
4. 如果函数中有变量（或其它东西）的类型发生了变化，那么之前JaegerMonkey和IonMonkey生成的jit代码都会被丢弃；以上的三个过程从头开始。

SpiderMonkey 这么设计是有原因的：解释器虽然很慢，但是能够保证执行的结果总是正确的；而IonMonkey虽然能够让编译之后的代码执行速度变快，但是需要花费很多的时间来编译；如果IonMonkey编译的代码执行次数很少，那么反而会导致总体的运行时间变长；而JaegerMonkey处于两者之间，能够用比IonMonkey少的时间生成比解释器速度快的代码，因此它被作为一个折中。

这样的设计很完美，不是么？

不，有几个重要的问题。

问题

• JaegerMonkey和IonMonkey都没有能力收集类型信息，但是它们依赖类型信息来生成代码。
• JaegerMonkey和IonMonkey的调用规范是不一样的，这导致两个JIT生成的代码之间的相互调用成本很高。
• 解释器收集类型信息的功能具有局限性，并不能满足IonMonkey的需求。
• 类型推断机制需要大量的内存，而类型推断的作者 Brian Hackett 表示把 JaegerMonkey 抛开之后事情会简单很多。
• 很多 JavaScript 代码执行的次数很少，连 JaegerMonkey 不会被调用。SpiderMonkey 在 SunSpider 测试集得分上落后很大程度上就是因为这个原因。
• JaegerMonkey 写得太复杂了，我们真的不想继续维护了 🙂

解决方案

我们使用 Baseline JIT 解决这些问题。它的优点：

• 代码比JaegerMonkey和IonMonkey都简单；
• 不会失效（invalidate）；
• 可以收集类型信息，inline cache机制可以帮助收集更多类型信息；
• 比解释器快10～100倍

致谢

Baseline was developed by Jan De Mooij and myself（注：Kannan Vijayan）, with significant contributions by Tom Schuster and Brian Hackett. Development was greatly helped by our awesome fuzz testers Christian Holler and Gary Kwong.

And of course it must be noted Baseline by itself would not serve a purpose. The fantastic work done by the IonMonkey team, and the rest of the JS team provides a reason for Baseline’s existence.

Firefox 18 发布了，新闻说启用了IonMonkey JIT的SpiderMonkey性能提升了25%（Kraken）。今天测试了一下，发现在 Linux上，Firefox 18 比 Firefox 17 的提升，甚至可以达到 47%，跟 Chromium 的速度旗鼓相当。以下是用我的台式机跑出来的 Kraken、V8、SunSpider、Octane 四个Benchmark的结果。

Kraken Benchmark

Firefox 18

详细结果

Firefox 17

详细结果

Firefox 18 vs. Firefox 17

（为了防止折行，将“FROM”和“TO”列隐去了，可以参看上面的结果）：

从结果来看引入了IonMonkey之后加速了将近47%。但是同时，个别程序性能反而下降了。

Chromium

作为对比，一并测试了一下 Chromium 的得分，版本号 18.0.1025.168（详细结果）：

 

总体上而言还是 Chromium 快一点，但是得分很接近，在一些分项上 Firefox 18.0 速度比Chromium更快。

Firefox 18.0 vs Chromium

 

Sunspider 0.91 Benchmark

SunSpider 0.9.1 的测试结果，有点意外的是 Firefox 17.0.1 最快，其次是Firefox 18.0，Chromium最慢。嗯，一定是我打开的方式不对。

测试地址：http://www.webkit.org/perf/sunspider-0.9.1/sunspider-0.9.1/driver.html

Firefox 18.0

详细结果

 

Chromium

详细结果

Firefox 17.0.1

详细结果

V8-v7 Benchmark

V8的测试结果，Firefox 18.0 > Chromium > Firefox 17.0.1

测试地址：http://v8.googlecode.com/svn/data/benchmarks/v7/run.html

Firefox 18.0

Score: 7671

Richards: 8811
DeltaBlue: 10991
Crypto: 11226
RayTrace: 6761
EarleyBoyer: 11968
RegExp: 904
Splay: 9461
NavierStokes: 15932

Chromium

Score: 7298

Richards: 10584
DeltaBlue: 14030
Crypto: 13852
RayTrace: 8836
EarleyBoyer: 19236
RegExp: 2368
Splay: 3268
NavierStokes: 2974

Firefox 17.0.1

Score: 5695

Richards: 6499
DeltaBlue: 7061
Crypto: 9931
RayTrace: 3211
EarleyBoyer: 7682
RegExp: 1447
Splay: 7603
NavierStokes: 8945

Octane v1 Benchmark

最后是 Octane 的测试结果。Octane Benchmark 的结果是一个分数，得分越高越好。总体得分来看，Chromium > Firefox 18.0 > Firefox 17.0.1。

关于这个Benchmark，Mozilla的开发人员Nicholas Nethercote并不认可，发表了一篇博客，认为测试程序的选取不具有代表性，过度的考虑了Chrome Apps。

测试地址：http://octane-benchmark.googlecode.com/svn/latest/index.html

Firefox 18：

Octane Score: 6754
Richards 8977
Deltablue 9984
Crypto 9910
Raytrace 6326
EarleyBoyer 11472
Regexp 634
Splay 9192
NavierStokes 15768
pdf.js 3452
Mandreel 6184
GB Emulator 8755
CodeLoad 7924
Box2DWeb 6940

Firefox 17：

Octane Score: 5618

Richards 6365
Deltablue 7425
Crypto 9962
Raytrace 3217
EarleyBoyer 7217
Regexp 1410
Splay 7896
NavierStokes 8877
pdf.js 4050
Mandreel 5447
GB Emulator 5096
CodeLoad 8622
Box2DWeb 5306

Chromium 18.0

Octane Score: 7735

Richards 8804
Deltablue 14116
Crypto 13961
Raytrace 9028
EarleyBoyer 19073
Regexp 2419
Splay 3726
NavierStokes 3112
pdf.js 10526
Mandreel 7992
GB Emulator 11014
CodeLoad 8310
Box2DWeb 5498

说明

• 测试的机器的配置是 Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz， 8G DDR2， Ubuntu 10.04 x86_64。
• 我机器上的 Chromium 的版本号似乎比 Chrome 的小，不确定是不是最新的版本（用的 stable release channel），对于测试结果有影响。
• 发现默认情况下Firefox 17和Firefox 18不会同时运行。Firefox在启动的时候会检查一下是否已经有了Firefox进程，如果有的话就不开新的进程了。这使得在测试的时候必须先关闭所有的Firefox浏览器窗口才能够换一个版本。为了避免乌龙我在每次测试之前，通过“About Firefox”菜单确认了版本。
• 这个测试结果仅限于Linux，在Windows环境下或许是完全另外的一个结果。相比而言各个浏览器对于Linux环境下的性能优化都不是很上心，小小失落。

这是本博客2013年的第一篇博客，献给刚入手的树梅派（Raspberry Pi，RBP） 🙂

拿到手的第一件事情就是浏览器性能测试。下载 Mozilla 源代码，编译 SpiderMonkey Shell（jsshell）进行测试。我使用的OS是树梅派官网的镜像包，按照SpiderMonkey的wiki一路走下来就可以编译成功。

编译的时间意外的长，超过了一个小时。

下面是SunSpider测试集的结果。每个测试都跑了100次，没有设置jsshell命令行参数。看起来树梅派的性能还是不太给力，可能是不太适合做计算密集型的工作。

SunSpider-1.0 测试集结果（在我的PC上是200ms，速度相差了46倍）

============================================
RESULTS (means and 95% confidence intervals)
——————————————–
Total: 9231.6ms +/- 0.3%
——————————————–

3d: 1691.6ms +/- 0.6%
cube: 588.9ms +/- 0.5%
morph: 409.0ms +/- 2.1%
raytrace: 693.7ms +/- 0.3%

access: 1171.5ms +/- 0.8%
binary-trees: 189.2ms +/- 1.4%
fannkuch: 277.4ms +/- 0.1%
nbody: 313.6ms +/- 0.7%
nsieve: 391.3ms +/- 1.8%

bitops: 527.2ms +/- 0.1%
3bit-bits-in-byte: 46.5ms +/- 0.3%
bits-in-byte: 168.1ms +/- 0.2%
bitwise-and: 158.3ms +/- 0.1%
nsieve-bits: 154.3ms +/- 0.3%

controlflow: 58.8ms +/- 0.3%
recursive: 58.8ms +/- 0.3%

crypto: 975.4ms +/- 0.7%
aes: 605.6ms +/- 0.9%
md5: 241.1ms +/- 0.5%
sha1: 128.8ms +/- 0.7%

date: 1349.5ms +/- 0.3%
format-tofte: 758.5ms +/- 0.4%
format-xparb: 591.0ms +/- 0.4%

math: 861.2ms +/- 0.6%
cordic: 219.7ms +/- 0.1%
partial-sums: 485.7ms +/- 0.9%
spectral-norm: 155.7ms +/- 1.1%

regexp: 289.1ms +/- 0.1%
dna: 289.1ms +/- 0.1%

string: 2307.3ms +/- 0.5%
base64: 275.6ms +/- 1.5%
fasta: 344.2ms +/- 1.2%
tagcloud: 673.9ms +/- 0.4%
unpack-code: 732.1ms +/- 0.6%
validate-input: 281.5ms +/- 0.9%

 

ubench测试集结果：

============================================
RESULTS (means and 95% confidence intervals)
——————————————–
Total: 13391.6ms +/- 0.9%
——————————————–

function: 9965.3ms +/- 1.2%
closure: 674.9ms +/- 2.3%
empty: 1078.0ms +/- 0.1%
correct-args: 1093.7ms +/- 0.1%
excess-args: 3940.2ms +/- 2.1%
missing-args: 2370.2ms +/- 2.8%
sum: 808.4ms +/- 0.1%

loop: 3426.2ms +/- 0.1%
empty-resolve: 182.4ms +/- 0.2%
empty: 1506.0ms +/- 0.1%
sum: 1737.8ms +/- 0.1%

 

v8-v4测试集结果：

============================================
RESULTS (means and 95% confidence intervals)
——————————————–
Total: 9294.2ms +/- 0.4%
——————————————–

3d: 1702.0ms +/- 0.7%
cube: 591.4ms +/- 0.4%
morph: 410.5ms +/- 2.2%
raytrace: 700.0ms +/- 0.4%

access: 1175.1ms +/- 0.7%
binary-trees: 190.6ms +/- 1.4%
fannkuch: 280.4ms +/- 0.3%
nbody: 315.6ms +/- 0.7%
nsieve: 388.5ms +/- 1.6%

bitops: 530.1ms +/- 0.2%
3bit-bits-in-byte: 46.8ms +/- 0.4%
bits-in-byte: 169.1ms +/- 0.3%
bitwise-and: 159.4ms +/- 0.3%
nsieve-bits: 154.7ms +/- 0.4%

controlflow: 59.1ms +/- 0.4%
recursive: 59.1ms +/- 0.4%

crypto: 982.6ms +/- 0.6%
aes: 610.9ms +/- 0.9%
md5: 242.9ms +/- 0.6%
sha1: 128.8ms +/- 0.5%

date: 1361.7ms +/- 0.3%
format-tofte: 763.2ms +/- 0.3%
format-xparb: 598.5ms +/- 0.5%

math: 868.8ms +/- 0.7%
cordic: 220.9ms +/- 0.2%
partial-sums: 490.7ms +/- 1.0%
spectral-norm: 157.2ms +/- 1.1%

regexp: 291.2ms +/- 0.2%
dna: 291.2ms +/- 0.2%

string: 2323.7ms +/- 0.5%
base64: 277.0ms +/- 1.6%
fasta: 346.5ms +/- 1.1%
tagcloud: 678.3ms +/- 0.4%
unpack-code: 737.7ms +/- 0.6%
validate-input: 284.1ms +/- 1.1%

 

这是目前的一些简单的心得：

• 我的树梅派是在淘宝上买的，中国版B，512M内存，价格319，加上一个8G Class10的SD卡和快递，390元。在Element14上也有卖的，价格298，不知道有没有加快递和税收。淘宝卖家简单直接，不还价，总体感觉不错。
• 第一次启动的时候需要初始化一下，这个时候是需要外接到显示器的，可以用HDMI-VGA转接头接到显示器上，或者用视频线直接接到电视机上。我是直接外接到电视机，设置好了IP地址，SSH登录就OK了。新买HDMI-VGA价格在30～120不等。
• RBP手册要求供电USB输出750mA以上。我用普通的USB手机充电器做的电源，600mA输出，同时接USB无线键鼠、网线和电视机没有问题。但是HDMI转VGA的时候显示器总是闪，不知道是不是功率的问题。
• 在电视机上开Firefox测试SunSpider，需要很久才有结果，没有耐心测试完。

在线测试了一下笔记本上Windows环境下三个浏览器的 SunSpider 0.9.1 跑分，竟然是 Chrome 落后。不过绝对的分值看起来都差不多。具体的数据如下：

Browser	Score(ms)
Firefox 15.0.1	400.2ms +/- 2.1%
IE 9.0.10	408.3ms +/- 2.0%
Chrome 22.0.1229.79	426.9ms +/- 7.8%
Firefox 14.0.1	471.9ms +/- 2.7%

实验用的机器是老机器，所以跑出来的时间都比较长。

如果你有兴趣，可以点击这里测试一下你的浏览器得分。