Experiments with 'Static' JavaScript: As Fast As Native Code? | Hacker News Reader

Experiments with 'Static' JavaScript: As Fast As Native Code?

mozakai.blogspot.com

52 pointsmbrubeck10 comments

Bit of a silly article IMO.

1) Given a perfect compiler, once compiled any interpreted code would be as fast as a native implementation.

2) How good a job your compiler does is dependent on many things, majorly the complexity of the code being compiled.

Fannkuch is extremely trivial code and really boils down to indirect array manipulation. It's interesting when comparing native/interpreted code because it indicates how much overhead is incurred with indirect memory access, but it's not something that provides any indication of how statically compiled javascript would generally perform against native code.

But if a JavaScript program - or part of a program - happens to be implicitly statically typed, and in other ways 'performance-friendly', then we should be able to compile at least such code and run it very quickly.

You don't need static typing in order to compile to machine code.

No, but it saves you having to emit machine code that does type checking and dispatch at run-time. You need type information if you want inner-loop performance that is competitive with languages (like C) that are designed for efficient compilation.

The generated code for something like "a = b + c" is very, very different if you know at compile-time whether b and c are strings or numbers or something else. Modern JavaScript VMs go to a lot of effort to guess or infer type information before JIT compilation.

Actually modern JavaScript engines depend on dynamic type discovery (via different forms of tracing) much more than on global static analysis.

Is there a good analysis anywhere on the pros/cons of that, and what languages it's most suited to? Lisp is also a dynamically typed (and otherwise quite dynamic) language, yet SBCL uses static type inference for its optimizations instead. Some difference in Lisp v. Javascript, or just different choices by the implementors?

> So, how about if we could compile JavaScript into native code?

Isn't that what all modern JavaScript engines do? If so, how are the results for the experiment so good? My guess is that he didn't take the compilation time into account in his own method.

Anything compiled to native code is going to be fast by comparison. (They are just characters in a text file.) The trick is to do it with all the features of an interpreter.

Somebody should measure fannkuchredux in Opera and compare that with C implementation speed. For some scenarios Opera's Javascript JIT already achieves speeds close to C.

check out shed skin, a Python to C++ compiler: http://code.google.com/p/shedskin/

JavaScript + static types = ActionScript 3

Reply on news.ycombinator.com