4 ms·

There's a VERY good reason why JS runtimes use JIT's, it's more or less impossible to properly fully type a JS program w/o leaving runtime holes. If you restri

There's a VERY good reason why JS runtimes use JIT's, it's more or less impossible to properly fully type a JS program w/o leaving runtime holes. If you restrict yourself to a subset or are willing to risk incompatiblities then it will work. There's some TypeScript to Wasm compilers that should work reasonably well (If you're breaking TS rules you've got yourself to blame a bit more than with JS). Ref: My thesis was on JS AOT and even if I had the idea of making it commercial I didn't pursue it in the end.

ushakov 3y ago
AssemblyScript works fine too! WASM and JS isn’t a good combination atm.
ignoramous 3y ago
> My thesis was on JS AOT Is it available online?
- deleted 3y ago
  [deleted]
- whizzter 3y ago
  Yes, it was written for other students so it's not as clean as most of the referred research papers. Part of the work was implementing a compiler whilst part of was surveying how well real world JS developers would understand language subset limitations. Most relevant for my above comment re AOT vs JIT is that JS semantics (I think I touched upon it in the thesis) will have the same issues that made JIT's win out with BigInts in the Agesen&Hölzle paper (whilst the paper is on AOT's my goal was to find a solution for game developers so numerical performance was a non-moving goal for me). My thesis http://kth.diva-portal.org/smash/record.jsf?pid=diva2%3A823252&dswid=-3627 http://kth.diva-portal.org/smash/record.jsf?pid=diva2%3A8232... Agesen & Hölze on JIT vs AOT https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=e07752a69ee34b97659502efe528942fa395d7a3 https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&d...
  - ignoramous 3y ago
    Thanks.
spankalee 3y ago
QuickJS and SpiderMonkey in WASM don't use JIT though - they're both just interpreters. WASM itself is often JIT'ed so a JS-to-WASM compiler that functions like the common JS baseline compilers would still get some benefit of JIT'ing even though the types available to the ICs in WASM may not be as useful as in JS. https://cfallin.org/blog/2023/10/11/spidermonkey-pbl/#future-compiled-code https://cfallin.org/blog/2023/10/11/spidermonkey-pbl/#future... has some interesting ideas on enabling the SpiderMonkey baseline compiler for WASM and possibly using partial evaluation to see better types.

ushakov 3y ago

AssemblyScript works fine too! WASM and JS isn’t a good combination atm.

ignoramous 3y ago

> My thesis was on JS AOT Is it available online?

deleted 3y ago
[deleted]
whizzter 3y ago
Yes, it was written for other students so it's not as clean as most of the referred research papers. Part of the work was implementing a compiler whilst part of was surveying how well real world JS developers would understand language subset limitations. Most relevant for my above comment re AOT vs JIT is that JS semantics (I think I touched upon it in the thesis) will have the same issues that made JIT's win out with BigInts in the Agesen&Hölzle paper (whilst the paper is on AOT's my goal was to find a solution for game developers so numerical performance was a non-moving goal for me). My thesis http://kth.diva-portal.org/smash/record.jsf?pid=diva2%3A823252&dswid=-3627 http://kth.diva-portal.org/smash/record.jsf?pid=diva2%3A8232... Agesen & Hölze on JIT vs AOT https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=e07752a69ee34b97659502efe528942fa395d7a3 https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&d...
- ignoramous 3y ago
  Thanks.

spankalee 3y ago

QuickJS and SpiderMonkey in WASM don't use JIT though - they're both just interpreters. WASM itself is often JIT'ed so a JS-to-WASM compiler that functions like the common JS baseline compilers would still get some benefit of JIT'ing even though the types available to the ICs in WASM may not be as useful as in JS. https://cfallin.org/blog/2023/10/11/spidermonkey-pbl/#future-compiled-code https://cfallin.org/blog/2023/10/11/spidermonkey-pbl/#future... has some interesting ideas on enabling the SpiderMonkey baseline compiler for WASM and possibly using partial evaluation to see better types.