5 ms·

This project is super impressive. It makes me wonder why there's not a similarly mature JavaScript AOT compiler implementation for use in game development or ot

This project is super impressive. It makes me wonder why there's not a similarly mature JavaScript AOT compiler implementation for use in game development or other places where you want performance better than a VM and you're not allowed to JIT. A small recommendation for these release pages would be to link to the tag in whatever source host you're using! I just want to see the code.

maattdd 5y ago
There is, for example https://bellard.org/quickjs/ https://bellard.org/quickjs/
- eatonphil 5y ago
  That's an interpreter written in C and without a JIT. Not the same as an AOT compiler. https://github.com/bellard/quickjs/blob/master/quickjs-opcode.h https://github.com/bellard/quickjs/blob/master/quickjs-opcod... The point isn't just not having a JIT. You can run v8 without a JIT. The point is good performance without a JIT.
  - BiteCode_dev 5y ago
    "Can compile Javascript sources to executables with no external dependency"
    - eatonphil 5y ago
      > @item -c > Only output bytecode in a C file. The default is to output an executable file. > @item -e > Output @code{main()} and bytecode in a C file. The default is to output an executable file. https://github.com/bellard/quickjs/blob/master/doc/quickjs.texi#L159 https://github.com/bellard/quickjs/blob/master/doc/quickjs.t...
    - formerly_proven 5y ago
      Which probably works by stapling bytecode to a precompiled interpreter. A tried and true strategy, but not necessarily what people want when asking for AOT compilation.
      - mappu 5y ago
        It's only a few steps away from what Graal/Truffle do: unroll the interpreter loop over the bytecode, then keep re-running dead code elimination and inlining passes - you end up with something very close to optimized native output.
        pjmlp 5y ago
        Specially since Graal/Truffle do include a JIT, which even has better optimization heuristics than Hotspot.
- deleted 5y ago
  [deleted]
pjmlp 5y ago
Not really what you are after, but it does use AOT (via generated C++ code). https://arcade.makecode.com/ https://arcade.makecode.com/ https://makecode.com/language https://makecode.com/language
- eatonphil 5y ago
  > In case of microcontrollers, PXT programs are compiled in the browser to ARM Thumb assembly, and then to machine code, resulting in a file which is then deployed to the microcontroller, usually via USB mass-storage interface. Looks like the only compilation strategy is directly to ARM Thumb assembly or did I miss something?
  - pjmlp 5y ago
    Maybe my memory is fuzzy about the exact workflow, in any case you can check "Microsoft MakeCode: from C++ to TypeScript and Blockly (and Back)" https://www.youtube.com/watch?v=tGhhV2kfJ-w https://www.youtube.com/watch?v=tGhhV2kfJ-w and the respective C++ FFI, https://makecode.com/simshim https://makecode.com/simshim
Scarbutt 5y ago
Because it will require tons of resources to make it more performant that the current JS JITs and it will probably fail. So what you see is some games just embedding V8.
kevin_thibedeau 5y ago
You'd be stuck with float numerics everywhere because there's no fallback to recompile if an attempt to use integer fails.
- gnulinux 5y ago
  compile both, dispatch dynamically in runtime.
  - kevin_thibedeau 5y ago
    It wouldn't be a "both" situation. Every number in a block of code may or may not be representable as an integer. You can't generate code for every possible combination.
tylerhou 5y ago
The main slowdown in JavaScript is because it is inherently so dynamic — all function calls are "virtual," properties are string lookups, you need a lot of indirection (boxing) to store objects. Without actually running the program on some input, it is infeasible to determine what those indirections will resolve to. So static compilation is useless (or would produce instructions very similar to what an interpreter would execute). That's why we usually interpret the code (and JIT it to optimize places where the program is not actually dynamic). Theoretically you could "precompile" JavaScript by running your code on some known input and caching the VM's state. Then you can "hydrate" your VM with that state. But this would only speed up the VM warmup (which is not that long) and requires significant browser/VM buy-in, so it is probably infeasible. The only way to produce better performance in JavaScript is to restrict it to a less-dynamic subset (e.g. objects must have static keys) and add at least some static typing so that a compiler can resolve some references ahead of time. That's why asm.js was a thing. But asm.js has been superseded by WASM, which better in most regards.
- vlovich123 5y ago
  Have you seen the work Fastly discussed about their AOT compiler? Seems like an interesting approach that maybe could be used to preprocess code into a more efficient form before running it in the cloud. The challenge is that JS engines are primarily focused on the browser and such an optimization opportunity isn’t interesting there - the majority of development is done by browser vendors.

maattdd 5y ago

There is, for example https://bellard.org/quickjs/ https://bellard.org/quickjs/

eatonphil 5y ago
That's an interpreter written in C and without a JIT. Not the same as an AOT compiler. https://github.com/bellard/quickjs/blob/master/quickjs-opcode.h https://github.com/bellard/quickjs/blob/master/quickjs-opcod... The point isn't just not having a JIT. You can run v8 without a JIT. The point is good performance without a JIT.
- BiteCode_dev 5y ago
  "Can compile Javascript sources to executables with no external dependency"
  - eatonphil 5y ago
    > @item -c > Only output bytecode in a C file. The default is to output an executable file. > @item -e > Output @code{main()} and bytecode in a C file. The default is to output an executable file. https://github.com/bellard/quickjs/blob/master/doc/quickjs.texi#L159 https://github.com/bellard/quickjs/blob/master/doc/quickjs.t...
  - formerly_proven 5y ago
    Which probably works by stapling bytecode to a precompiled interpreter. A tried and true strategy, but not necessarily what people want when asking for AOT compilation.
    - mappu 5y ago
      It's only a few steps away from what Graal/Truffle do: unroll the interpreter loop over the bytecode, then keep re-running dead code elimination and inlining passes - you end up with something very close to optimized native output.
      - pjmlp 5y ago
        Specially since Graal/Truffle do include a JIT, which even has better optimization heuristics than Hotspot.
deleted 5y ago
[deleted]

pjmlp 5y ago

Not really what you are after, but it does use AOT (via generated C++ code). https://arcade.makecode.com/ https://arcade.makecode.com/ https://makecode.com/language https://makecode.com/language

eatonphil 5y ago
> In case of microcontrollers, PXT programs are compiled in the browser to ARM Thumb assembly, and then to machine code, resulting in a file which is then deployed to the microcontroller, usually via USB mass-storage interface. Looks like the only compilation strategy is directly to ARM Thumb assembly or did I miss something?
- pjmlp 5y ago
  Maybe my memory is fuzzy about the exact workflow, in any case you can check "Microsoft MakeCode: from C++ to TypeScript and Blockly (and Back)" https://www.youtube.com/watch?v=tGhhV2kfJ-w https://www.youtube.com/watch?v=tGhhV2kfJ-w and the respective C++ FFI, https://makecode.com/simshim https://makecode.com/simshim

Scarbutt 5y ago

Because it will require tons of resources to make it more performant that the current JS JITs and it will probably fail. So what you see is some games just embedding V8.

kevin_thibedeau 5y ago

You'd be stuck with float numerics everywhere because there's no fallback to recompile if an attempt to use integer fails.

gnulinux 5y ago
compile both, dispatch dynamically in runtime.
- kevin_thibedeau 5y ago
  It wouldn't be a "both" situation. Every number in a block of code may or may not be representable as an integer. You can't generate code for every possible combination.

tylerhou 5y ago

The main slowdown in JavaScript is because it is inherently so dynamic — all function calls are "virtual," properties are string lookups, you need a lot of indirection (boxing) to store objects. Without actually running the program on some input, it is infeasible to determine what those indirections will resolve to. So static compilation is useless (or would produce instructions very similar to what an interpreter would execute). That's why we usually interpret the code (and JIT it to optimize places where the program is not actually dynamic). Theoretically you could "precompile" JavaScript by running your code on some known input and caching the VM's state. Then you can "hydrate" your VM with that state. But this would only speed up the VM warmup (which is not that long) and requires significant browser/VM buy-in, so it is probably infeasible. The only way to produce better performance in JavaScript is to restrict it to a less-dynamic subset (e.g. objects must have static keys) and add at least some static typing so that a compiler can resolve some references ahead of time. That's why asm.js was a thing. But asm.js has been superseded by WASM, which better in most regards.

vlovich123 5y ago
Have you seen the work Fastly discussed about their AOT compiler? Seems like an interesting approach that maybe could be used to preprocess code into a more efficient form before running it in the cloud. The challenge is that JS engines are primarily focused on the browser and such an optimization opportunity isn’t interesting there - the majority of development is done by browser vendors.