-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
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:
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 |
@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. |
@MaxGraey You are expert on this. Mozilla achieved even faster WASM->JS call than JS->JS. |
@otabekgb Yes, calling function which contain only plain parameter types like |
We already have an optimal way to executing TS - the V8 JIT compiler. |
@ry why even bother writing whole new engine then? |
With some flags, support compiling typescript sources to webassembly, by using compilers like assemblyscript. This should give additional performance benefit.
The text was updated successfully, but these errors were encountered: