The Missing Tool In Scripting World

# Andrea Giammarchi (14 years ago)

Just because in this ml there are many engineers involved in JS engines optimizations ... this is a "what if..." post, feel free to comment it or hopefully take some hint out of it: webreflection.blogspot.com/2011/10/missing-tool-in-scripting-world.html

Best

# Sam Tobin-Hochstadt (14 years ago)

On Sun, Oct 16, 2011 at 8:52 AM, Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote:

Just because in this ml there are many engineers involved in JS engines optimizations ... this is a "what if..." post, feel free to comment it or hopefully take some hint out of it: webreflection.blogspot.com/2011/10/missing-tool-in-scripting-world.html

The initial premise of your post: "The main difference between scripting languages and statically typed one is the inability to pre optimize or pre compile the code before it's actually executed." is not correct. As two examples, Steel Bank Common Lisp [1] and Larceny Scheme [2] both precompile to x86 machine code and heavily optimize ahead of time, despite not compiling statically typed languages. If you look here [3], you can see numerous scripting languages (such as Python, Ruby, ActionScript, and Lua) that compile to LLVM.

[1] www.sbcl.org [2] www.larcenists.org [3] llvm.org/Users.html

# Andrea Giammarchi (14 years ago)

not natively, and not in the optimized way C or C++ do with the exception of ActionScript that compiles similar way Java does.

Consider I did not want to provide all possible details about compilers, JIT, and tracers, but at least in JS this compiler is missing. Maybe I should update with this note ?

# Axel Rauschmayer (14 years ago)

The email archived under at the following location is pertinent to this discussion, too.

lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043719.html

In this email, I argue that LLVM IR is a poor system for building a Platform, by which I mean any system where LLVM IR would be a format in which programs are stored or transmitted for subsequent use on multiple underlying architectures.

# Sam Tobin-Hochstadt (14 years ago)

On Sun, Oct 16, 2011 at 12:05 PM, Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote:

not natively, and not in the optimized way C or C++ do

This is not correct -- SBCL and Larceny (and many other systems) generate optimized native code, exactly like C and C++ do.

with the exception of ActionScript that compiles similar way Java does. Consider I did not want to provide all possible details about compilers, JIT, and tracers, but at least in JS this compiler is missing.

The reason that JS implementations do not use an ahead-of-time compiler is not because the (very good) implementors of V8 and Spidermonkey and JSC and Chakra and Carakan aren't smart enough to do it. It's because unique aspects of the JavaScript platform encourage extremely low latency for compilation, and because the implementors believe (correctly, I think) that JIT compilation is a better way to achieve their performance goals for JS than ahead-of-time compilation.

# Andrea Giammarchi (14 years ago)

LLVM is just an example, the concept of "being able to predict what will be through testing" and generate statically compilable code better represents the point of that post :-)

# Andrea Giammarchi (14 years ago)

my idea is to analyze code at runtime via unit tests providing all expected inputs and outputs ... whatever the JIT can do, it can do the same at that time and produce an already JITed byte code out of it.

If there is a tracer, things can go even better so that JS could produce native executable code ... AFAIK not possible right now