CodeGen for WebAssembly

[ghost]

WebAssembly (wasm): http://webassembly.github.io/

According to MicrosoftEdge status page -> https://developer.microsoft.com/en-us/microsoft-edge/platform/status/webassemblymvp?filter=f3f0000bf&search=WebAssembly, WebAssembly is in development.

IMO, it would be great to consolidate efforts right from the beginning between Edge, CoreCLR/CoreRT and VC teams to provide robust WebAssembly code generation and optimizations.

In case of LLILC the LLVM compiler has already started to support WebAssembly, but having first hand code gen in CoreCLR has its own advantages. Perhaps we can have a draft implementation started in CoreCLR where community can chime in?

[jkotas]

WebAssembly version of CoreCLR would be pretty hard to do. CoreRT is better candidate for this.

It should not be hard to built a small demo - using CoreRT CppCodeGen - that compiles and runs a simple program as WebAssembly. It can be then iterated on from there (e.g. generate the WebAssembly directly without going through CppCodeGen, etc.).

[jkotas]

https://github.com/WebAssembly/design/blob/master/GC.md would be likely required to make WebAssembly work as .NET Runtime target.

[ghost]

Thanks @jkotas!

There is their official tool-chain for experimentation: https://github.com/WebAssembly/binaryen.

Here are the simple build steps for Windows (VC++ build tools / VS2015) which I just updated:https://github.com/brakmic/brakmic/blob/master/webassembly/COMPILING_WIN32.md.

In four simple commands (given msbuild v14+, cmake 3+ and git 2+ in PATH):

git clone https://github.com/WebAssembly/binaryen.git --recursive
cd binaryen
cmake .
cmake --build . --config Release

it produces assembler, disassembler, linker and decompiler etc.:

asm2wasm.exe
binaryen-shell.exe
binaryen.dll
binaryen.js
empty.txt
s2wasm.exe
wasm-as.exe
wasm-dis.exe
wasm.js

We can probably incorporate this tool-chain (or take some inspirations) for CoreRT and add the spec suite as a submodule to validate the conformance.

Can you please take a look and point me to the area of CppCodeGen to focus on so I don't get lost in figuring out the starting point. :)

[jkotas]

"Using CPP Code Generator" steps at https://github.com/dotnet/corert/blob/master/Documentation/how-to-build-and-run-ilcompiler-in-visual-studio-2015.md are probably the best place to start.

[svick]

ilwasm, an incomplete IL to wasm compiler might also be of interest.

[ghost]

@kg, do you think the CoreRT route would help ilwasm project or somehow efforts can be combined to build something awesome? I am scratching the surface with binaryen's S-Expression builder in conjunction with 'building ilcompiler' doc suggested by @jkotas above.

[kg]

You could AOT-compile large portions of an application to webassembly, yes. Given the runtime constraints, though, I don't know how far this would get you. I believe Unity does an IL->C++->x mapping right now with Emscripten, and that approach generally works, but is constrained.

[ghost]

Related: WASM MVP progress on JavaScript engine: https://github.com/Microsoft/ChakraCore/issues/1127.

[Thaina]

Nearly a year now we have working webassembly on browser

Are there any plan we could hope for yet?

[kg]

The initial version of the WebAssembly spec is missing some things you'd need for a first-class .NET implementation, but a stripped down version of .NET applications might be feasible. Lots of legwork to be done to prove it, though.

[listepo]

Any news?

[Thaina]

@kg I wish we don't need to AOT the C#. Because webassembly actually don't need AOT. IL should directly convert to wasm. Both system could do dynamic codegen

I use unity webgl everyday and I would like to say that it totally impractical. Round trip and limitation caused by unnecessary AOT is too much headache

[zezba9000]

Funny how Mono ran on nacl and pnacl for years without the need for AOT. I remember running Unity3D's version (and a custom build) on old Linux computers with NaCl and it ran fast and used very little ram. Now with WASM or asm.js, its slow and uses tons of ram. Really wish pnacl had just been adopted across browsers instead (as it has been powerful and full featured for years [.NET Core could probably be make to run on it without AOT]).

For now because the .NET eco system still lacks a "stable" cross platform UI you might look into using Bridge.NET. If you're writing games, not sure whats faster though, Bridge.NET, JSIL or Unity3D for C#.

[kg]

WASM will eventually be able to handle JIT (at least for some scenarios), so the question is how long it will take for it to arrive, and whether WASM JIT will be performant or expressive enough to cut it for .NET Core's runtime or for Unity games. My informed guesses would be based on dated information, since I haven't been involved in the WASM spec process for a while.

For more limited scenarios where you just need to JIT a little code at runtime, you can generate blobs of regular JS and let the javascript VM compile those on the fly to interact with your heap. Your performance is going to suffer though, from the 1-2 punch of losing WASM optimizations and having to reach across the WASM foreign function interface (it has pinvoke-ish overhead for crossing runtime boundaries, much like asm.js)

When it comes to performance right now your best bet is still an Emscripten-based toolchain (Unity3d uses it). The main caveat is that the Emscripten approach has startup time and memory usage issues but the performance (once started) is difficult to beat. Emscripten can also produce WebAssembly executables right now, IIRC.

[zezba9000]

but the performance (once started) is difficult to beat

From benchmarks I've seen on the web for rendering instanced objects in WebGL, pnacl was around 4x as fast as asm.js in real world situations. Same goes for physics simulations. WASM / asm.js might be good notions but I see it as a regressive effort for what exists today in the Chrome browser. Not all competition is healthy (but thats a different matter).

[Thaina]

For such times we was thinking about webassembly approach as compilation target for C# or IL so we need to build a compiler for translation. But I have seen some small size VM was built to run VM itself in the webassembly

So is it possible that we could build the coreCLR / coreRT itself into VM on webassembly and just throw pure IL into that VM?

[gulshan]

https://github.com/aspnet/Blazor-Hackathon seems relevant.

[zezba9000]

Blazor-Hackathon uses DotNetAnywhere (DNA) which is an interpreted .NET runtime. Bridge.NET which compiles to JS probably gets better performance. We need CoreRT to function like Unity's IL2CPP so we can target any C compiler and thus any platform/environment with minimal work.

[Thaina]

@zezba9000 Isn't dotnet core written in C++? If so can we just emscripten it?

[zezba9000]

@Thaina No because the JIT has to made to support each platform target, x86, x64, ARM, MIPS, SPARK, RISC-V, WASM, etc. If you compile .NET IL directly to "C98" for example (like the NIM lang) you could target almost any platform out there with little work (its why Unity3D made IL2CPP). I would guess the GC would be the part needing tweaks to get it working on some platforms. In fact with a GC designed for low memory devices you could probably replace .NET Micro with CoreRT getting huge performance and memory usage boosts.

[morganbr]

We’ve started a WebAssembly experiment in the CoreRT repo and we need your help! Take a look at https://github.com/dotnet/corert/issues/4659 for more details on what’s happening and how to get involved.

[AndyAyersMS]

Think we can probably close this as the linked CoreRT issue should cover it.

[morganbr]

Sounds good. Closing against dotnet/corert#4659.