这篇文章仅仅针对浏览器处理JavaScript的性能作比较，主要在X86平台和龙芯平台。先来解释一下JavaScript，JavaScript是互联网内较为常用的脚本语言，面向对象，主要在浏览器内解释执行，用于生成动态网页，因为很多语言特性受Java影响，所以叫JavaScript。通过JavaScript，浏览器可以运行服务器想要在访问者终端上运行的一些计算程序，以达到更好的浏览体验。

再说说浏览器内核和JavaScript的关系，其实JavaScrip脚本的执行仅仅是浏览器内核的一部分，其他的还有Html语言的解释执行，网页的呈现等等也是内核要做的。之所以这么关心浏览器核心对JavaScript脚本的处理情况，是因为现在的很多应用不再是简单的网页浏览，如gmail，google reader，gooe wave还有一些网页3D特效等等都需要在客户机上作计算，这就需要JavaScript大显身手了。而且越来越多的应用依赖JavaScript，所以现在浏览器对JavaScript的处理速度直接影响着用户体验。目前WebKit的JavaScript引擎SquirrelFish，JavaScript的引擎是SpiderMonkey

目前JavaScript在大多数平台上的处理是靠解释执行的，又因为是动态类型，面向对象。。。，决定了JavaScript执行效率低，所以就诞生了各种针对JavaScript的优化，也有了测试JavaScipt解释器性能的BenchMark，目前常用的是Sunspider和google V8，这篇文章中的对比针对Sunspider测试集。

另外还要说说JIT，Just In time，转换，将部分程序代码直接转换成机器码执行，这种技术在运行时优化中比较常用，JavaScript是解释器，所以JIT在解释器中也是很重要的优化手段。目前X86的webkit和Firefox默认就有JIT支持，但龙芯平台上还没有，本博也是最早对龙芯2F平台有JIT支持的Webkit和firefox  JavaScript引擎作对比的，目前这两个JIT都还没有进入官方的代码库中，感兴趣的朋友可以在下面的前两个链接中找到相关源码。其中webkit的补丁还要做些宏的修改，改动不大。这两个都是从官方源码库checkout出来并修改之后的。其中firefox的JIT部分是由ZSC大牛写出来的，详细的讨论贴和测试结果可以在龙芯论坛看到，见下面的第三个链接。
x86下epiphany(webkit内核)和firefox开了jit之后的性能，如下

webkit Total:                  833.6ms +/- 2.1%
firefox Total:                 1774.4ms +/- 2.7%

（测试环境是我的笔记本 intel Pentium t2390,开了频率调节，所以波动较大)、两个差距：

TEST                   COMPARISON            FROM                 TO             DETAILS

=============================================================================

** TOTAL **:           2.13x as fast     1774.4ms +/- 2.7%   833.6ms +/- 2.1%     significant

=============================================================================

  3d:                  2.96x as fast      257.2ms +/- 2.1%    87.0ms +/- 1.0%     significant
    cube:              3.36x as fast       79.2ms +/- 1.7%    23.6ms +/- 2.9%     significant
    morph:             1.52x as fast       50.4ms +/- 1.4%    33.2ms +/- 3.1%     significant
    raytrace:          4.23x as fast      127.6ms +/- 3.0%    30.2ms +/- 3.4%     significant

  access:              3.26x as fast      237.0ms +/- 4.7%    72.8ms +/- 2.8%     significant
    binary-trees:      8.82x as fast       67.0ms +/- 4.4%     7.6ms +/- 9.0%     significant
    fannkuch:          3.48x as fast       98.2ms +/- 0.6%    28.2ms +/- 3.7%     significant
    nbody:             2.50x as fast       51.4ms +/- 10.3%    20.6ms +/- 3.3%     significant
    nsieve:            -                   20.4ms +/- 56.6%    16.4ms +/- 4.2% 

  bitops:              1.42x as fast       53.8ms +/- 1.9%    38.0ms +/- 0.0%     significant
    3bit-bits-in-byte: *3.10x as slow*      2.0ms +/- 0.0%     6.2ms +/- 9.0%     significant
    bits-in-byte:      -                   11.0ms +/- 8.0%    10.4ms +/- 6.5%
    bitwise-and:       *2.33x as slow*      3.0ms +/- 0.0%     7.0ms +/- 0.0%     significant
    nsieve-bits:       2.62x as fast       37.8ms +/- 1.5%    14.4ms +/- 4.7%     significant

  controlflow:         8.76x as fast       50.8ms +/- 2.0%     5.8ms +/- 9.6%     significant
    recursive:         8.76x as fast       50.8ms +/- 2.0%     5.8ms +/- 9.6%     significant

  crypto:              2.34x as fast       93.8ms +/- 1.7%    40.0ms +/- 2.2%     significant
    aes:               2.57x as fast       54.0ms +/- 3.6%    21.0ms +/- 4.2%     significant
    md5:               2.62x as fast       26.2ms +/- 2.1%    10.0ms +/- 0.0%     significant
    sha1:              1.51x as fast       13.6ms +/- 5.0%     9.0ms +/- 0.0%     significant

  date:                1.87x as fast      275.2ms +/- 2.0%   147.0ms +/- 1.0%     significant
    format-tofte:      2.75x as fast      149.0ms +/- 1.0%    54.2ms +/- 1.0%     significant
    format-xparb:      1.36x as fast      126.2ms +/- 4.0%    92.8ms +/- 1.7%     significant

  math:                1.12x as fast       89.8ms +/- 1.8%    80.2ms +/- 21.7%     significant
    cordic:            2.13x as fast       43.4ms +/- 3.3%    20.4ms +/- 9.2%     significant
    partial-sums:      *1.41x as slow*     34.4ms +/- 2.0%    48.6ms +/- 38.2%     significant
    spectral-norm:     1.07x as fast       12.0ms +/- 0.0%    11.2ms +/- 12.2%     significant

  regexp:              3.73x as fast      125.4ms +/- 15.5%    33.6ms +/- 2.0%     significant
    dna:               3.73x as fast      125.4ms +/- 15.5%    33.6ms +/- 2.0%     significant

  string:              1.80x as fast      591.4ms +/- 3.3%   329.2ms +/- 1.6%     significant
    base64:            *1.24x as slow*     28.4ms +/- 2.4%    35.2ms +/- 1.6%     significant
    fasta:             1.71x as fast      133.0ms +/- 2.3%    78.0ms +/- 4.6%     significant
    tagcloud:          2.81x as fast      169.4ms +/- 3.8%    60.2ms +/- 8.2%     significant
    unpack-code:       1.91x as fast      193.8ms +/- 4.4%   101.6ms +/- 2.7%     significant
    validate-input:    1.23x as fast       66.8ms +/- 5.8%    54.2ms +/- 6.4%     significant

龙芯上的JIT具体对比数据不便透漏，可以从下面第三个链接中找到第一版发布时的测试数据。这里仅仅给出一个对比。webkit之所以with GUI是使用编译出的迷你小浏览器中测试结果，no GUI是使用测试脚本跑出来的结果。

 Webkit with GUI Total:                  6723.4ms +/- 0.5%
        no GUI   Total:                  6355.8ms +/- 0.5%
 Firfox Total 7000 ms 左右。

注： 龙芯中的JIT现在还不够成熟，其中Webkit的JIT仅是针对MIPS III做的，没有针对龙芯的特殊优化。

另外，X86中firefox的版本是3.5.7，龙芯中firefox的版本是3.7pre1.WebKit在X86中版本是epiphany的2.28中的版本，龙芯中为SVN中的2010-01-12 r53114。X86运行环境为Gentoo，Gcc4.4.2,Glibc2.11,龙芯运行环境是玲珑一体机，GCC4.3(龙梦修改版）,Glibc2.10。

对比结果可见：X86中WebKit浏览器的性能要明显优于Firefox，达到两倍之多。龙芯相比起来还有些差距，不过相信优化后龙芯的性能会更好。

参考

https://bugs.webkit.org/show_bug.cgi?id=30144

http://dev.lemote.com/code/firefox-3.7-loongson-jit

http://lemote.com/bbs/viewthread.php?tid=26687&extra=page%3D1

http://en.wikipedia.org/wiki/Google_Chrome

http://ineolee.com/pc/several-browser-core-introduction/

您可能也喜欢：
zzMozilla的疯狂构想 Firefox 4将开拓浏览器新疆界	JIT Compiler and Virtual Machine SW Engineer for Web Browsers in Qualcomm	webkit-龙小组成立	龙芯N32系统上的Squirrelfish性能	擦亮眼睛 “百度Hi”用户协议有猫腻
无觅

相关文章：

• 拥有Nanojit龙芯后端的firefox发布(10年1月14日更新)
• GCC初窥
• 用crossdev装龙芯的n32 gnu交叉工具链
• 使用crossdev安装龙芯的O32 gnu交叉工具链
• Gentoo中的交叉编译利器–crossdev
• 龙芯N32系统上的Squirrelfish性能

Javascript的JIT后端，原先firefox直接使用javascript解释器，效率比较低。nanojit可以将频繁执行的javascript代码直接翻译为机器码执行，效率更高，性能更好。详细的介绍可以参看这篇文章：an overview of TraceMonkey，  (我是中国人，我要看中文 ).本博还有一篇英文介绍，自己的蹩脚英语拙作。确实闲着无聊可以猛击这里。

• 咋又蹦出来个tracemonkey？

这得先从spidermonkey说起，spidermonkey是firefox里的Javascprit解释器。因为增加了Nanojit，这种通过跟踪(trace)热JAVAscript代码的JIT。所以改名叫tracemonkey。

• 我只关心这个firefox！

那就从这个地址下载吧，firefox_release.mips1-1_mipsel.deb. 下载之后切换到root帐号或者直接执行。注意目前Nanojit只测试了O32的龙芯，龙芯默认的操作系统和其他Debian衍生系统都能使用(目前测试了debian-en和Rays,没有问题).目前2E和2F的机器都能使用。N32的gentoo系统还不支持。

sudo dpkg -i firefox_release.mips1-1_mipsel.deb

然后执行firefox命令就行了(若su 切换到root安装且遇到No display specified 错，你可能需要先退出root账户).

安装的这个firefox是基于mozilla-central中最新的3.7a1pre修改而来，虽然在测试中，没发现firefox本身很多bug，但不排除这种可能性。所以用之前您得心里有底 : )

注意，两个不同版本的firefox不能同时运行。你如果想测试性能的话，需要先关掉，再启动另一个。

• 这个命令都在我可爱的龙芯电脑上做了啥？

呵呵，别紧张，它只是在/usr/local下安装了支持Nanojit的firefox，修改的文件夹有share，bin ，lib和include。你原来的firefix还在。安装了之后默认会启动新安装的这个firefox。如果你仍然想换回原来的，可以修改PATH中的搜索次序。

• 给我个理由先，为啥要装它

一句话概括，执行javascript时貌似有点快，貌似？！对，因为目前优化还少，大部分工作在做后端的移植和调试工作。以后将会有优化和提升。所以不排除你的某些应用无法得到很高的加速。但是它毕竟有点快，使用Sun spider测试集，加速比1.73.我运行了gmail，速度还行，呵呵.详细的讨论见龙芯论坛的讨论贴loongson上firefox的nanojit支持

• 博主真絮叨，能做出这么牛的东西？

问的好！呵呵，不是我做的。是某牛人 zsc做的。我只是猥琐的趁机将其拿来为我的小博赚点流量。不过若你有什么问题，可以在lingcc.com，或者到上面的龙芯论坛的帖子中讨论:)

• 最近更新2010-01-14

改进正则表达式处理，nanojit加速比由1.73上升到2.18.增加Thundbird中的nanojit支持，
下载最新mozilla_1-1_mipsel.deb（有龙芯Nanojit支持的firfox,2010年1月14日)
下载最新thunderbird3-ls_1-1_mipsel.deb(有龙芯Nanojit支持的Thunderbird，2010年1月14日）
你也可以从这里找到详细的源码下载和编译指导：http://dev.lemote.com/code/firefox-3.7-loongson-jit/

为支持龙芯的开源爱好者们，加油！

Enjot it !

您可能也喜欢：

GCC即将支持龙芯3A

龙芯中科公司招聘JAVA虚拟机开发工程师

关于龙芯公司的小道消息

胡伟武：龙芯5年内改变全球CPU格局

zz 龙芯之火，可以燎原（上）

无觅

相关文章：

• WebKit和Firefox的JavaScript性能对比
• 用crossdev装龙芯的n32 gnu交叉工具链
• 使用crossdev安装龙芯的O32 gnu交叉工具链
• GCC初窥
• 前瞻-LLVM大事记(2004-2010)
• 为龙芯电脑安装操作系统常见问题

TraceMonkey simply identifies loop back edges and do the optimization only on loops.  every loop back edge is a potential trace point.The loop becomes hot on its second iteration,so TraceMonkey records the code along the trace in a low-level compiler intermediate representation LIR(In Nanojit, LIR is the source language for compilation to machine code. LIR stands for low-level intermediate representation.) .TraceMonkey stops recording when execution returns to the loop header or exits the loop.After recording is finished,TraceMonkey compiles the trace to native code using the recorded type information for optimization.These code can be entered if the interpreter PC and the types of values match those observed when trace recording was started.

When Tacemonkey detects a loop header and when the loop header has been executed 2 times, It starts a tree to record the trace and type map and mark the trace as the root of a tree.

Then the backend of TraceMonkey-Nanojit comes up ,It will turn the traced LIR to native code .nanojit is part of the tracemonkey,which will translate the recorded trace to an optimized machine code tree.

Traces are in SSA form and have no join points or phi-nodes.And the optimizaions of nanojit must run quickly.Every time the trace recorder emits a LIR instruction,the instruction is immediately passed to pipeline filters which will do optimizations.

There are two types of filters: forward filters and backward filters. The forward filters will do some constant subexpression elimination,expression simplification,then the trace will be recorded. When the recording is completed,nanojit runs the backward optimization filters.nanojit reads one LIR instruction ata a time,and pass it through the pipeline. backward filters do dead data-stack store elimination ,dead call-stack store elimination and dead code elimination optimizations. After a LIR instruction is successfully read from the backward filter pipeline,nanojit’s code generator emit native machine instructions for it.

Register allocation in nanojit is a simple greedy algorithm.It makes a single backward paass over the trace and use a class heuristic that selects the “oldest” register carried values.

So,How does TraceMonkey coorperate with firefox?

Compiled traces are stored in a trace cache,indexed by interpreter PC and type map,The intepreter must hit a loop edge and enter the monitor in order to call a native trace for the first time.To execute a trace, the monitor must build a trace activation record containing imported local and global variables, temporary stack space, and space for arguments to native calls.The local and global values are then copied from the interpreter state to the trace activation record,then the trace is called like a normal C function pointer.
When a trace call returns.the monitor first checks the reason for the trace exit,then it pops or synthesizes interpreter JavaScript call stack frames as needed, finally it copies the impored variables back from the trace activation record to the interpreter state.

您可能也喜欢：
The importance of being updated	zzMozilla的疯狂构想 Firefox 4将开拓浏览器新疆界	gentoo的相关配置-make.conf	Ebuild and emerge	擦亮眼睛 “百度Hi”用户协议有猫腻
无觅

相关文章：

• 拥有Nanojit龙芯后端的firefox发布(10年1月14日更新)
• 安装LLVM2.7 step by step
• Open64课程-结语
• GCC初窥
• WebKit和Firefox的JavaScript性能对比
• Open64课程-循环嵌套优化(LNO)