Deno: Typescript to webassembly compilation

Created on 20 Mar 2019  路  11Comments  路  Source: denoland/deno

With some flags, support compiling typescript sources to webassembly, by using compilers like assemblyscript. This should give additional performance benefit.

Most helpful comment

@MaxGraey You are expert on this. Mozilla achieved even faster WASM->JS call than JS->JS.
If mozilla did this, V8 will do it either. WASM optimizations are only at babysteps.
https://hacks.mozilla.org/2018/10/calls-between-javascript-and-webassembly-are-finally-fast-%F0%9F%8E%89/

All 11 comments

@otabekgb I highly doubt it. V8 is very highly optimised, much better than I would assume assemblyscript would be, especially when it comes to things like GC and fast pathing code.

I think to even consider it, a performance proof of concept would be needed, even then I highly suspect there would be lots of issues in accessing and supporting non-TC39 APIs, like the browser ones and the Deno ones.

I would be glad to be proven wrong. Deno supports web assembly, so taking a TypeScript application (one that is representative of a performance benchmark) running it under Deno against a .wasm transpiled version would give a good idea of potential performance. Ideally it would also do importing of more than one module to see how that would work in a real world application.

If we conditionally divide the code into two parts:

  1. initialization code that is executed very rarely, and sometimes only once;
  2. hot code that runs quite often and usually optimize pretty well by JS JIT compiler.

WebAssembly/AssemblyScript could definitely speed up first part (1). You could see this real world benchmark for confirm this. But as for code (2) this may not always be true, oddly enough. Especially if only some part of it is ported because interop between js <-> wasm overhead could be significant sometimes. You can achieve a certain good result only if you port the whole deno's typescript library to the webassembly and communicate directly with the Rust's host.

Also probably make sense rewrite/rebuild some algorithms from Rust native to wasm like cryptography

Having played around with assemblyscript in the past it's important to note that typescript code designed to be compiled to javascript is not inherently compatible with assemblyscript. You couldn't just take any library from std for instance and just compile it to wasm using assemblyscript, and expect it to work. Assemblyscript is designed for writing low level wasm logic using the typescript tools and syntax, so really assemblyscript is more of it's own language in this respect. Support for assemblyscript could be added in the form of #1739, though it might not play nice with editor integration since you would need a separate extension(maybe .as or .ats). There might be performance to be gained here, but it's obviously not as simple as just compiling to wasm.

@kitsonk I highly doubt, V8 can compete with statically typed language. Runtime type checking overhead will always be performed in V8, even after hot path optimization

Another benefit of webassembly is the parsing speed and the consizeness

@afinch7 Assemblyscript is compatible with typescript as far as it can. It is natural to require not to use ANY type, because compiler should know the types exactly. It is also recommended to use ANY only for backward compatibility with legacy JS. Also specific number types are introduced to make bare-metal optimization, otherwise they could have used DOUBLE internally like JS.
My idea is to use webassembly whenever possible, by mixing TS->WASM and TS->JS and adding glue-code automatically. But the future should be increasingly WASM code

@MaxGraey You are expert on this. Mozilla achieved even faster WASM->JS call than JS->JS.
If mozilla did this, V8 will do it either. WASM optimizations are only at babysteps.
https://hacks.mozilla.org/2018/10/calls-between-javascript-and-webassembly-are-finally-fast-%F0%9F%8E%89/

@otabekgb Yes, calling function which contain only plain parameter types like number is quite fast for now especially in Mozilla browser but passing objects, strings and array still require additional allocations, copy/clone and serializations/de-serializations (or encoding/decoding) until anyref and host-binding proposal not yet landed

We already have an optimal way to executing TS - the V8 JIT compiler.

@ry why even bother writing whole new engine then?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

zugende picture zugende  路  3Comments

justjavac picture justjavac  路  3Comments

benjamingr picture benjamingr  路  3Comments

JosephAkayesi picture JosephAkayesi  路  3Comments

kitsonk picture kitsonk  路  3Comments