Benefits of Javascript Engines

Question

I'm confused about JavaScript engines right now. I know that V8 was a big problem because it compiled JavaScript for native code.

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 so, why doesn't Firefox do this?

Finally, Rhino literally compiles JavaScript byte code in Java to take full advantage of Java's speed. If not, why don't people launch V8 when writing scripts on their desktops?

Answer 1

There are various approaches to executing JavaScript, even when executing JIT. V8 and Nitro (formerly known as SquirrelFish Extreme) decided to make the whole JIT method, which means that they compile all the JavaScript code into inline instructions when they run into the script, and then just execute it as if it were compiled with C code . SpiderMonkey instead uses JIT "tracing", which first compiles the script into bytecode and interprets it, but monitors execution by looking for "hot spots" such as loops. When he discovers one, he then compiles only this hot path to machine codes and does it in the future.

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

The JIT tracing implemented in SpiderMonkey can create extremely specialized code compared to the JIT of the whole method, since it has already executed the code and can speculate on the types of variables (for example, treat the index variable in a for loop as a native integer), where the JIT of the whole method should process a variable as an object, because JavaScript is untyped, and the type can change (SpiderMonkey will simply “fall off” the trace if this assumption fails, and return to the interpretation of the bytecode). However, the SpiderMonkey JIT trace does not currently work efficiently with code with many branches, since the traces are optimized for single execution paths. In addition, some premiums are involved in monitoring before deciding whether to compile a trace, and then switch execution to that trace. In addition, if the tracer makes an assumption that is later violated (for example, the type of change in the variable), the cost of dropping the trace and returning to interpretation is likely to be higher than using the whole method JIT.

Answer 2

V8 is the fastest as it compiles all JS for machine code.

SpiderMonkey (which uses FF) is also very fast, but compiles to intermediate bytecode, not machine code. This is a big difference with the V8. EDIT. Newer versions of Firefox come with a newer version of SpideMonkey; TraceMonkey. TraceMonkey does JIT compilation of critical parts and possibly other smart optimizations.

Rhino compiles Javascript into Java classes, which allows you to basically write Java applications in Javascript. Rhino is also used as a way to interpret JS in the backend and manipulate it and have a complete understanding of the code, such as reflection. This is used, for example, by a YUI compressor.

The reason Rhino is used instead of V8 everywhere is probably because V8 is relatively new, so many projects already use Rhino / Spidermonkey as their JS engine, like Yahoo widgets. (I assume you mean "scripts on your desktops")

Edit- This link may also give some insight into why SpiderMonkey is so widely accepted. What Javascript engine do you embed in your application?

Answer 3

If you want to see how various browser-based Javascript mechanisms work out, install Safari 4 (yes, it now works on Windows too!), Chrome V8, Firefox 3.5, and IE 8 (if you're on windows) and run the test:

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

I believe that, as Walkney said, the new Firefox 3.5 uses TraceMonkey, which also compiles for intermediate code on the fly using some form of JIT. So it should be compared with the V8 somewhat profitable. At least it won't be 10 times slower than V8 like Firefox 3 SpiderMonkey (without JIT).

For me ... Safari 4.0.3 was 2.5x faster than Tracemonky in Firefox 3.5.3 on Win XP. IE8 was much slower. Chrome is not currently installed.

Don't know about compiling Rhino for java bytecode. If it still interprets dynamic Javascript functions, such as the ability to add attributes to object instances at runtime (example obj.someNewAttribute = "someValue", which is allowed in Javascript) ... I'm not sure if it is fully "compiled" "to bytecode, and you cannot get better performance, except that you don’t have to compile from the Javascript source code each time you run Javascript. Remember that Javascript has very dynamic syntax like eval ("x = 10; y = 20; z = x * y "); which means that you can create ki of code that compiles at runtime, so I would think that Rhino would be interpreted / compiled in mixed mode, even if you compiled the JVM bytecode.

The JVM is still an interpreter, albeit a very good one with JIT support. Therefore, I like to think of Rhino-on-JVM as two layers of interpreter (interpreter-translator) or interpreter ^ 2. While most of your other Javascript engines are written in C, and as such should do more as an interpreter ^ 1. Each the interpreter level can add a 5-10-fold decrease in performance compared to C or C ++ (for example, Perl or Python or Ruby), but with JIT the performance hit can be significantly lower than about 2-4x. And the JVM has one of the most reliable and mature JIT engines.

Thus, your mileage will definitely change, and you are likely to benefit from some serious tests if you want a real answer for your intended application on your own hardware and OS.

Rhino cannot be too terribly slow since I know that many use it. I think the main attraction is not its speed, but the fact that it is an easy-to-use code / lightweight / embeddable / interpreter that has hooks in Java libraries, which makes it ideal for scripting / configuration / extensibility of your software project. Some text editors, such as UltraEdit, even embed Javascript as an alternative macro script engine. It seems that every programmer is able to easily stumble through javascript, so it is easy to pick it up.

One of the advantages of Rhino is that it works almost everywhere the JVM works. In my experience, trying to create a standalone TraceMonkey or SpiderMonkey to create and run from the command line can be a little painful on systems like Windows. And embedding into your application can be even more time consuming. But the payback of having a nested language will be worth it for a large project, compared with the need to "minimize your" mini-scripting solution if that is what you want to do.

Scripting with Rhino is very easy, if you have Java and a rin river, you just write your javascript and run it from the command line. I use it all the time for simple tasks.

Answer 4

To answer the question why native code Vs Bytecode ...

Native code is also faster for Google - a strategic choice, because they have a JS plan, one of which, at least, is ChromeOS.

A good video about this issue is published on Channel9 with an interview with Lars Buck, the person behind V8 can be found here.