Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Typescript to webassembly compilation #1980

Closed
otabekgb opened this issue Mar 20, 2019 · 11 comments
Closed

Typescript to webassembly compilation #1980

otabekgb opened this issue Mar 20, 2019 · 11 comments

Comments

@otabekgb
Copy link

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

@kitsonk
Copy link
Contributor

kitsonk commented Mar 20, 2019

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

@MaxGraey
Copy link
Contributor

MaxGraey commented Mar 20, 2019

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.

@MaxGraey
Copy link
Contributor

MaxGraey commented Mar 21, 2019

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

@afinch7
Copy link
Contributor

afinch7 commented Mar 21, 2019

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.

@otabekgb
Copy link
Author

@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

@otabekgb
Copy link
Author

Another benefit of webassembly is the parsing speed and the consizeness

@otabekgb
Copy link
Author

@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

@otabekgb
Copy link
Author

otabekgb commented Mar 25, 2019

@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/

@MaxGraey
Copy link
Contributor

MaxGraey commented Mar 25, 2019

@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

@ry
Copy link
Member

ry commented Mar 25, 2019

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

@ry ry closed this as completed Mar 25, 2019
@jayarjo
Copy link

jayarjo commented May 30, 2020

@ry why even bother writing whole new engine then?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants