Experiments with 'Static' JavaScript: As Fast As Native Code?
mozakai.blogspot.com
Experiments with 'Static' JavaScript: As Fast As Native Code?
1–10 of 12 posts
Re: Experiments with 'Static' JavaScript: As Fast As Native Code?
#2Anything 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.
Re: Experiments with 'Static' JavaScript: As Fast As Native Code?
#3But 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.
Re: Experiments with 'Static' JavaScript: As Fast As Native Code?
#4Anything 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]
Re: Experiments with 'Static' JavaScript: As Fast As Native Code?
#5But 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.
Re: Experiments with 'Static' JavaScript: As Fast As Native Code?
#6JavaScript + static types = ActionScript 3
Re: Experiments with 'Static' JavaScript: As Fast As Native Code?
#7But 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 Java…
Actually modern JavaScript engines depend on dynamic type discovery (via different forms of tracing) much more than on global static analysis.
Re: Experiments with 'Static' JavaScript: As Fast As Native Code?
#8check out shed skin, a Python to C++ compiler: http://code.google.com/p/shedskin/
Re: Experiments with 'Static' JavaScript: As Fast As Native Code?
#9Bit 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.
Re: Experiments with 'Static' JavaScript: As Fast As Native Code?
#10Somebody 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.