Javascript引擎优势 [英] Javascript Engines Advantages

问题描述

我现在对JavaScript引擎感到困惑。我知道 V8 是一个大问题，因为它将JavaScript编译为本机代码。

I am confused about JavaScript engines right now. I know that V8 was a big deal because it compiled JavaScript to native code.

然后我开始阅读 Mozilla SpiderMonkey ，据我所知，是用C编写的，可以编译JavaScript。那么这与V8有什么不​​同呢？如果这是真的，为什么Firefox不这样做？

Then I started reading about Mozilla SpiderMonkey, which from what I understand is written in C and can compile JavaScript. So how is this different from V8 and if this is true, why does Firefox not do this?

最后， Rhino 从字面上编译JavaScript到Java字节码，这样你就可以获得Java的所有速度优势？如果没有，为什么人们在桌面上编写脚本时不运行V8？

Finally, does Rhino literally compile the JavaScript to Java byte code so you would get all the speed advantages of Java? If not, why do people not run V8 when writing scripts on their desktops?

推荐答案

有各种JavaScript执行方法，甚至在做JIT时。 V8和Nitro（以前称为SquirrelFish Extreme）选择执行一个完整的JIT方法，这意味着他们在遇到脚本时将所有JavaScript代码编译成本机指令，然后简单地执行它就像编译C代码一样。 SpiderMonkey使用跟踪JIT，它首先将脚本编译为字节码并对其进行解释，但监视执行情况，寻找诸如循环之类的热点。当它检测到一个时，它会编译机器代码的热路径，并在将来执行。

There are various approaches to JavaScript execution, even when doing JIT. V8 and Nitro (formerly known as SquirrelFish Extreme) choose to do a whole-method JIT, meaning that they compile all JavaScript code down to native instructions when they encounter script, and then simply execute that as if it was compiled C code. SpiderMonkey uses a "tracing" JIT instead, which first compiles the script to bytecode and interprets it, but monitors the execution, looking for "hot spots" such as loops. When it detects one, it then compiles just that hot path to machine code and executes that in the future.

这两种方法都有好处和缺点。整个方法JIT确保所有执行的JavaScript都将被编译并作为机器代码运行而不被解释，这通常应该更快。但是，根据实现，它可能意味着引擎花费时间编译永远不会执行的代码，或者可能只执行一次，并且不是性能关键。此外，这个编译的代码必须存储在内存中，这样可以导致更高的内存使用量。

Both approaches have upsides and downsides. Whole-method JIT ensures that all JavaScript that is executed will be compiled and run as machine code and not interpreted, which in general should be faster. However, depending on the implementation it may mean that the engine spends time compiling code that will never be executed, or may only be executed once, and is not performance critical. In addition, this compiled code must be stored in memory, so this can lead to higher memory usage.

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

The tracing JIT as implemented in SpiderMonkey can produce extremely specialized code compared to a whole-method JIT, since it has already executed the code and can speculate on the types of variables (such as treating the index variable in a for loop as a native integer), where a whole-method JIT would have to treat the variable as an object because JavaScript is untyped and the type could change (SpiderMonkey will simply "fall off" trace if the assumption fails, and return to interpreting bytecode). However, SpiderMonkey's tracing JIT currently does not work efficiently on code with many branches, as the traces are optimized for single paths of execution. In addition, there's some overhead involved in monitoring execution before deciding to compile a trace, and then switching execution to that trace. Also, if the tracer makes an assumption that is later violated (such as a variable changing type), the cost of falling off trace and switching back to interpreting is likely to be higher than with a whole-method JIT.

这篇关于Javascript引擎优势的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！