5 ms·

Ahead-of-time JavaScript compiler

34 points by apaprocki 11y ago

marssaxman 11y ago
Weird that the label specifies "ahead of time", which is implicit in "compiler", but does not mention that it is a Javascript-to-C++ translator rather than a normal machine-code-producing compiler.
- coldtea 11y ago
  >specifies "ahead of time", which is implicit in "compiler" Well, not that implicit, seeing that we also say "JIT compiler".
  - spacemanmatt 11y ago
    Doesn't that demonstrate the parent's point if we need to qualify it with "JIT" because "compiler" connotes if not implies AOT?
    - zem 11y ago
      No, it means that "compiler" now refers to both JIT and AOT compilers, so you technically need to disambiguate, even though AOT is enough in the majority that you can leave it to be assumed in practice.
- jestar_jokin 11y ago
  Java compiles to its own bytecode ahead of time. The standard JVM also makes use of JIT to compile hot code paths to machine code. Python compiles to its own bytecode, but only when a script is first interpreted. Haxe compiles to many different source code languages ahead of time, including C++, Python, Java, JavaScript, and C#. It also compiles to a custom "Neko VM" bytecode. So, "compiling" isn't necessarily ahead of time, depending on what level of "compilation" you're talking about.
  - marssaxman 11y ago
    It's not necessarily done ahead of time, but if someone says they've written a "compiler", without qualification, I'm going to understand that as a program for taking source code as input and producing an executable as output, because that is the platonic form of a "compiler". Of course there are other sorts of programs which still qualify as a "compiler", but I'd generally expect that if someone is going to add qualifiers to "compiler", they would start with the qualifiers which distinguish their tool from the platonic compiler. In this case the authors have added a qualifier which is included in the platonic compiler form, without mentioning a significant way their project differs from the platonic compiler form, and that struck me as amusing.
- ant6n 11y ago
  A compiler is a translator. It translates programs from one programming language to another. You always want to compile to the easiest target language that solves the problem well and allows you to do the optimizations you want to do. By compiling to C++, they can focus on static typing and closures etc., but don't have to worry about generating machine code, and register allocation and whatnot. Back in school, I worked on a project to compile Matlab. We picked Fortran as the target, because it was very similar in terms of operating on matrices. But it's typed, and had a few very fast compilers available.
  - marssaxman 11y ago
    Of course. I've written a compiler myself which used C++ as its output language. It just amused me that the authors made a point of specifying one characteristic of the program which is generally assumed as the default, while making no mention of another, far less common characteristic which effectively defines the scope of their project.
mtdewcmu 11y ago
It was only a matter of time before someone did this. Did it really take this long?
- rubiquity 11y ago
  AFAIK browsers have been doing this internally for years. It just hasn't been available as a standalone utility.
  - mtdewcmu 11y ago
    I don't think that's an accurate statement. If a browser implemented this, it could be considered a crude form of JIT. But JIT techniques were more sophisticated than this by the time browsers started using them on Javascript.
billylindeman 11y ago
but does the output compile with emscripten?
ahmacleod 11y ago
> It is not expected that the performance of compiled applications will ever rival 'v8'. JavaScript is an awful language for static compilation - it almost seems designed to foil any attempts at optimization, and so a JIT will always have a significant performance advantage. For the compiler un-initiated such as myself, is there a simplified explanation for why static compilation is inferior to JIT for languages like javascript?
- catmanjan 11y ago
  I'd also like to know the exact reasons, but I imagine it has something to do with types. With JIT you're only interested in the type of a variable when you're reading it, whereas ahead of time you'd have to account for many cases - I think this would be a big deal with JavaScript's inheritance model.
- jestar_jokin 11y ago
  For one, "this" could refer to anything at any time, depending on who invoked the enclosing function. function myFunc() { console.log(this); } var myObj = {}; // this = window myFunc(); // this = window myFunc.apply(null, []); // this = myObj myFunc.apply(myObj, []); myObj.myFunc = myFunc; // this = myObj myObj.myFunc(); var tmpFunc = myObj.myFunc; // this = window tmpFunc(); Another issues is closures, where variables and properties available to nested functions are dependent on the outer functions. Combined with the floating "this", leads to highly dynamic behaviour which can only be assessed at runtime.
  - userbinator 11y ago
    I'd guess the names of properties being possibly dynamically computed also makes things difficult to optimise.
    - jestar_jokin 11y ago
      A clever compiler might be able to infer "structural typing", which is basically "duck typing" done at compile time. So, if you add a property "bar" to an object "foo", and you have some other code that calls "baz.bar", you can infer that "foo" is of type "HasABar", and "baz" is of type "HasABar", therefore it might be safe to use "foo" in place of "baz". The tricky part would be consolidating every structural subtype into cohesive classes.
z92 11y ago
Transition the runtime to C [from C++] Wondering why? I thought C++ and C are comparable in speed.
- azth 11y ago
  They are. Practically anything that can be done in C, can be done in C++. At the same time, C++ offers ways to get better performance that are not available in C (e.g. templates). Even GCC moved from C to C++ for safety. This doesn't look like a very well thought out decision.

34 points by apaprocki 11y ago

Weird that the label specifies "ahead of time", which is implicit in "compiler", but does not mention that it is a Javascript-to-C++ translator rather than a normal machine-code-producing compiler.

coldtea 11y ago
>specifies "ahead of time", which is implicit in "compiler" Well, not that implicit, seeing that we also say "JIT compiler".
- spacemanmatt 11y ago
  Doesn't that demonstrate the parent's point if we need to qualify it with "JIT" because "compiler" connotes if not implies AOT?
  - zem 11y ago
    No, it means that "compiler" now refers to both JIT and AOT compilers, so you technically need to disambiguate, even though AOT is enough in the majority that you can leave it to be assumed in practice.
jestar_jokin 11y ago
Java compiles to its own bytecode ahead of time. The standard JVM also makes use of JIT to compile hot code paths to machine code. Python compiles to its own bytecode, but only when a script is first interpreted. Haxe compiles to many different source code languages ahead of time, including C++, Python, Java, JavaScript, and C#. It also compiles to a custom "Neko VM" bytecode. So, "compiling" isn't necessarily ahead of time, depending on what level of "compilation" you're talking about.
- marssaxman 11y ago
  It's not necessarily done ahead of time, but if someone says they've written a "compiler", without qualification, I'm going to understand that as a program for taking source code as input and producing an executable as output, because that is the platonic form of a "compiler". Of course there are other sorts of programs which still qualify as a "compiler", but I'd generally expect that if someone is going to add qualifiers to "compiler", they would start with the qualifiers which distinguish their tool from the platonic compiler. In this case the authors have added a qualifier which is included in the platonic compiler form, without mentioning a significant way their project differs from the platonic compiler form, and that struck me as amusing.
ant6n 11y ago
A compiler is a translator. It translates programs from one programming language to another. You always want to compile to the easiest target language that solves the problem well and allows you to do the optimizations you want to do. By compiling to C++, they can focus on static typing and closures etc., but don't have to worry about generating machine code, and register allocation and whatnot. Back in school, I worked on a project to compile Matlab. We picked Fortran as the target, because it was very similar in terms of operating on matrices. But it's typed, and had a few very fast compilers available.
- marssaxman 11y ago
  Of course. I've written a compiler myself which used C++ as its output language. It just amused me that the authors made a point of specifying one characteristic of the program which is generally assumed as the default, while making no mention of another, far less common characteristic which effectively defines the scope of their project.

mtdewcmu 11y ago

It was only a matter of time before someone did this. Did it really take this long?

rubiquity 11y ago
AFAIK browsers have been doing this internally for years. It just hasn't been available as a standalone utility.
- mtdewcmu 11y ago
  I don't think that's an accurate statement. If a browser implemented this, it could be considered a crude form of JIT. But JIT techniques were more sophisticated than this by the time browsers started using them on Javascript.

billylindeman 11y ago

but does the output compile with emscripten?

ahmacleod 11y ago

> It is not expected that the performance of compiled applications will ever rival 'v8'. JavaScript is an awful language for static compilation - it almost seems designed to foil any attempts at optimization, and so a JIT will always have a significant performance advantage. For the compiler un-initiated such as myself, is there a simplified explanation for why static compilation is inferior to JIT for languages like javascript?

catmanjan 11y ago
I'd also like to know the exact reasons, but I imagine it has something to do with types. With JIT you're only interested in the type of a variable when you're reading it, whereas ahead of time you'd have to account for many cases - I think this would be a big deal with JavaScript's inheritance model.
jestar_jokin 11y ago
For one, "this" could refer to anything at any time, depending on who invoked the enclosing function. function myFunc() { console.log(this); } var myObj = {}; // this = window myFunc(); // this = window myFunc.apply(null, []); // this = myObj myFunc.apply(myObj, []); myObj.myFunc = myFunc; // this = myObj myObj.myFunc(); var tmpFunc = myObj.myFunc; // this = window tmpFunc(); Another issues is closures, where variables and properties available to nested functions are dependent on the outer functions. Combined with the floating "this", leads to highly dynamic behaviour which can only be assessed at runtime.
- userbinator 11y ago
  I'd guess the names of properties being possibly dynamically computed also makes things difficult to optimise.
  - jestar_jokin 11y ago
    A clever compiler might be able to infer "structural typing", which is basically "duck typing" done at compile time. So, if you add a property "bar" to an object "foo", and you have some other code that calls "baz.bar", you can infer that "foo" is of type "HasABar", and "baz" is of type "HasABar", therefore it might be safe to use "foo" in place of "baz". The tricky part would be consolidating every structural subtype into cohesive classes.

z92 11y ago

Transition the runtime to C [from C++] Wondering why? I thought C++ and C are comparable in speed.

azth 11y ago
They are. Practically anything that can be done in C, can be done in C++. At the same time, C++ offers ways to get better performance that are not available in C (e.g. templates). Even GCC moved from C to C++ for safety. This doesn't look like a very well thought out decision.