Hacker News Reader

Comment by eatonphil | Hacker News Reader

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.

View on HN

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.

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.

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

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

"Can compile Javascript sources to executables with no external dependency"

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

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.

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.

Specially since Graal/Truffle do include a JIT, which even has better optimization heuristics than Hotspot.

Not really what you are after, but it does use AOT (via generated C++ code).

https://arcade.makecode.com/

https://makecode.com/language

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

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

and the respective C++ FFI,

https://makecode.com/simshim

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

compile both, dispatch dynamically in runtime.

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.

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.

Reply on news.ycombinator.com