【问题标题】:Javascript Engines AdvantagesJavascript 引擎的优势
【发布时间】:2011-01-09 09:19:00
【问题描述】:

我现在对 JavaScript 引擎感到困惑。我知道V8 很重要,因为它将 JavaScript 编译为本机代码。

然后我开始阅读Mozilla SpiderMonkey,据我了解,它是用 C 编写的,可以编译 JavaScript。那么这与 V8 有什么不同,如果这是真的,为什么 Firefox 不这样做呢?

最后,Rhino 是否真的将 JavaScript 编译为 Java 字节码,以便您获得 Java 的所有速度优势?如果不是,为什么人们在桌面上编写脚本时不运行 V8?

【问题讨论】:

标签: javascript v8 rhino spidermonkey javascript-engine


【解决方案1】:

JavaScript 执行有多种方法,即使在执行 JIT 时也是如此。 V8 和 Nitro(以前称为 SquirrelFish Extreme)选择执行全方法 JIT,这意味着它们在遇到脚本时将所有 JavaScript 代码编译为原生指令,然后像编译的 C 代码一样简单地执行它。 SpiderMonkey 改为使用“跟踪”JIT,它首先将脚本编译为字节码并对其进行解释,但会监视执行,寻找诸如循环之类的“热点”。当它检测到一个时,它就会将那个热路径编译为机器代码并在将来执行它。

这两种方法都有优点和缺点。全方法 JIT 确保所有执行的 JavaScript 都将作为机器代码编译和运行,而不是解释,这通常应该更快。但是,根据实现的不同,这可能意味着引擎花费时间编译永远不会执行的代码,或者可能只执行一次,并且对性能不是很重要。另外,这个编译后的代码必须存放在内存中,这样会导致内存占用较高。

与整体方法 JIT 相比,SpiderMonkey 中实现的跟踪 JIT 可以生成非常专业的代码,因为它已经执行了代码并且可以推测变量的类型(例如将 for 循环中的索引变量视为本机整数),其中整体方法 JIT 必须将变量视为对象,因为 JavaScript 是无类型的并且类型可能会改变(如果假设失败,SpiderMonkey 将简单地“脱落”跟踪,并返回解释字节码)。但是,SpiderMonkey 的跟踪 JIT 目前在具有许多分支的代码上不能有效地工作,因为跟踪针对单个执行路径进行了优化。此外,在决定编译跟踪之前监视执行会涉及一些开销,然后将执行切换到该跟踪。此外,如果跟踪器做出后来违反的假设(例如变量更改类型),则脱离跟踪并切换回解释的成本可能高于使用整体方法 JIT。

【讨论】:

  • 请注意,在这几年中,Firefox 已经切换到使用整体方法 JIT 以及“JaegerMonkey”并放弃了跟踪 JIT。
【解决方案2】:

V8 是最快的,因为它将所有的 JS 编译成机器码。

SpiderMonkey(FF 使用的)也很快,但编译为中间字节码,而不是机器码。这是与 V8 的主要区别。编辑 - 较新的 Firefox 版本带有较新的 SpideMonkey 变体;追踪猴子。 TraceMonkey 对关键部分进行 JIT 编译,也许还有其他智能优化。

Rhino 将 Javascript 编译成 Java 类,因此您基本上可以用 Javascript 编写“Java”应用程序。 Rhino 也被用作在后端解释 JS 并对其进行操作的一种方式,并具有完整的代码理解,例如反射。例如,YUI Compressor 使用它。

之所以到处使用Rhino而不是V8可能是因为V8比较新,所以很多项目已经使用Rhino/Spidermonkey作为他们的JS引擎,例如Yahoo widgets。 (我假设这就是您所说的“桌面上的脚本”)

编辑- 这个链接也可以让我们深入了解为什么 SpiderMonkey 被如此广泛地采用。 Which Javascript engine would you embed in your application?

【讨论】:

  • Umm TraceMonkey 也将 JIT 转换为机器代码......而且我认为说 V8 将 JavaScript “编译”为机器代码一点也不准确——它或多或少是相同的与 TraceMonkey 一样的 JIT 方法。
  • @Pointy,TraceMonkey 和 V8 之间的 AFAIK 区别在于 TraceMonkey 编译为中间代码,其中一些在执行时将 JIT 编译为机器代码。 V8 将所有内容直接编译为机器码。
  • "V8 在第一次执行时将 JavaScript 源代码直接编译成机器码。没有中间字节码,没有解释器。"来源:code.google.com/apis/v8/design.html 所以基本上像 C 编译器一样编译就可以了。还有,V8 编译所有 JS,TraceMonkey 做 JIT
【解决方案3】:

如果您想了解各种浏览器内 Javascript 引擎的组合方式,请安装 Safari 4(是的,它现在也可以在 Windows 上运行!)、Chrome V8、Firefox 3.5 和 IE 8(如果您在 Windows 上)和运行基准测试:

http://www2.webkit.org/perf/sunspider-0.9/sunspider.html

我相信正如 Pointy 上面所说的,新的 Firefox 3.5 使用 TraceMonkey,它还可以使用某种形式的 JIT 即时编译成中间编辑代码。所以它应该与 V8 相比略胜一筹。至少它不会像 Firefox 3 SpiderMonkey(没有 JIT)那样比 V8 慢 10 倍。

对我来说...safari 4.0.3 在 Win XP 上的 Firefox 3.5.3 中比 Tracemonky 快 2.5 倍。 IE8 要慢得多。我目前没有安装 Chrome。

不知道 Rhino 编译成 java 字节码。如果它仍在解释 Javascript 的动态特性,例如能够在运行时向对象实例添加属性(例如 obj.someNewAttribute="someValue" Javascript 中允许的)......我不太确定它是否完全“编译” " 到字节码,除了每次运行 Javascript 时不必从 Javascript 源代码文本编译之外,您可能不会获得任何更好的性能。请记住,Javascript 允许非常动态的语法,例如 eval("x=10;y=20;z=x*y");这意味着您可以构建在运行时编译的代码字符串。这就是为什么我认为即使你编译为 JVM 字节码,Rhino 也会被混合模式解释/编译。

JVM 仍然是一个解释器,尽管它支持 JIT 非常好。所以我喜欢将 Rhino-on-JVM 视为 2 个解释器层(interpreter-on-interpreter)或解释器^2。而您的大多数其他 Javascript 引擎都是用 C 编写的,因此应该更像解释器^1。与 C 或 C++(例如,参考 Perl 或 Python 或 Ruby)相比,每个解释器层可以增加 5-10 倍的性能下降,但使用 JIT,性能损失可能会低得多,大约为 2-4 倍。 JVM 拥有有史以来最强大和最成熟的 JIT 引擎之一。

因此,如果您想在自己的硬件和操作系统上为您的预期应用程序提供真正的答案,您可能会受益于做一些严肃的基准测试。

Rhino 不能太慢,因为我知道很多人都在使用它。我认为它的主要吸引力不是它的速度,而是易于编码/轻量级/可嵌入/解释器的事实,它与 Java 库挂钩,这使得它非常适合您的软件项目的脚本/配置/可扩展性。 UltraEdit 等一些文本编辑器甚至嵌入了 Javascript 作为替代宏脚本引擎。每个程序员似乎都能轻松地学习 javascript,因此也很容易上手。

Rhino 的一个优势是它几乎可以在 JVM 运行的任何地方运行。以我的经验,尝试让独立的 TraceMonkey 或 SpiderMonkey 从命令行构建和运行在 Windows 等系统上可能会有点痛苦。并且嵌入到您自己的应用程序中可能会更加耗时。但是对于一个大型项目来说,拥有一种可嵌入语言的回报是值得的,而不是如果你想要这样做,就必须“推出你自己的”迷你脚本解决方案。

如果你有 Java 和 rhino jar,用 Rhino 编写脚本真的很容易,你只需编写你的 javascript 并从命令行运行它。我一直用它来完成简单的任务。

【讨论】:

  • 我在我的 XP 机器上安装了 chrome 4,它运行 sunspider 基准测试的速度比 Firefox 3.5.3 Tracemonkey 快大约 3 倍。还发现与我之前使用 SpiderMonkey 的经验相比,V8 易于下载和构建。当然,您需要 svn + python 2.4 + scons 1.0.0 + Visual Studio 2005/2008(VC++ 2008 免费版据说也可以)所有这些我已经在我的开发人员 PC 上运行。公平地说,也许我会回去尝试再次构建 TraceMonkey,看看它现在的效果如何。
  • 请注意,Sunspider 不是唯一的答案,它只是一个 JavaScript 基准测试(尽管 JavaScript 引擎作者已经对其进行了大量优化)。
  • VC++ 2008 express(free) 确实适用于用 scons 编译 v8,本周早些时候做到了。
【解决方案4】:

回答这个问题,为什么原生代码与字节码...

本机代码更快,对于 google 来说是一个战略选择,因为他们计划 JS 其中至少之一是 ChromeOS。

关于这个问题的一个很好的视频发布在 Channel9 上,对 V8 背后的人 Lars Bak 的采访可以找到here

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-06-10
    • 1970-01-01
    • 2019-07-10
    • 2011-01-04
    • 1970-01-01
    • 2011-01-21
    相关资源
    最近更新 更多