4 ms·

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

52 points by mbrubeck 16y ago

jared314 16y ago
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.
- deleted 16y ago
  [deleted]
joubert 16y ago
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.
- mbrubeck 16y ago
  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.
  - andraz 16y ago
    Actually modern JavaScript engines depend on dynamic type discovery (via different forms of tracing) much more than on global static analysis.
    - _delirium 16y ago
      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?
tsta 16y ago
JavaScript + static types = ActionScript 3
danbmil99 16y ago
check out shed skin, a Python to C++ compiler: http://code.google.com/p/shedskin/ http://code.google.com/p/shedskin/
ajg1977 16y ago
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.
acqq 16y ago
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.
Amnon 16y ago
> 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.

52 points by mbrubeck 16y ago

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.

deleted 16y ago
[deleted]

joubert 16y ago

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.

mbrubeck 16y ago
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.
- andraz 16y ago
  Actually modern JavaScript engines depend on dynamic type discovery (via different forms of tracing) much more than on global static analysis.
  - _delirium 16y ago
    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?

tsta 16y ago

JavaScript + static types = ActionScript 3

danbmil99 16y ago

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

ajg1977 16y ago

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.

acqq 16y ago

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.

Amnon 16y ago

> 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.