Emscripten: Webassembly jit'ing emulator

[unicomp21]

@kripken crazy idea here ...

looking at jor1k, it's a pretty powerful concept with respect to quickly reusing the plethora of linux based source code available out in the world.

Would it make sense to have a jor1k emulator, or something similar, that could keep statistics and "jit" frequently used instructions into webassembly instructions? Or maybe some way to give hints to the emulator at runtime which mark start/end points for jit'ing. Seems to me, such an approach could eliminate a lot of the friction points currently experienced w/ emscripten.

I can't believe how fast jor1k starts up!

http://s-macke.github.io/jor1k/demos/main.html?user=3CZKesUytb&cpu=asm&n=1&relayURL=wss%3A%2F%2Frelay.widgetry.org%2F

Am I nuts, or could this actually be done?

[unicomp21]

I addition, we could make the virtual nic really fast using RTCDataChannel(s) for carrying the ethernet frames. Also, w/ the recent addition of wireguard to the linux kernel, the ethernet frames could be replaced w/ wireguard frames, allowing for construction of high throughput vpn's.

[unicomp21]

CC'ing @dcodeIO

[sbc100]

Are you are proposing that jor1k could be written in WebAssebmly rather then JavaScript? Its possible there could be wins from doing that but it would be complete rewrite.

In term of JIT support, there is not very much today in WebAssembly. You can generate entire modules on the fly and compile them from JavaScript, but its not very granular and I don't know of any projects doing that yet.

What do you mean by: "Seems to me, such an approach could eliminate a lot of the friction points currently experienced w/ emscripten."? How are you saying that instead of porting codebases to WebAssembly using emscripten we could instead emulate a CPU and just run the native linux binaries in the browser? I'm just trying to understand what you are suggesting.

[unicomp21]

My understanding, jor1k currently runs in webassembly, as an emulator compiled w/ emscripten.

An example, suppose I want to use all of boost and all c++ 20 features (ie ASIO w/ co_await), etc. This could be done w/ jor1k as it stands today, running within a browser. Simply do a git clone for whatever is needed and recompile on jor1k. I would not be able to do this today w/ emscripten.

For the most part, I think one could say, just about any source available in git can be leveraged in jor1k running in a browser.

The argument against the above would be the performance hit of using an emulation layer. The fix would be adding support for the emulation layer to "jit" itself into webassembly "as needed" by the user, using runtime hints or statistics, etc.

We take the initial stance of being able to use everything, and then provide functionality which allows us to optimize from there.

[sbc100]

Im not sure running your code inside a linux kernel which itself it running inside a CPU emulator is going to very practical for most users who want to target the web. Its cool and it for sure could have some uses, but maybe not as a way to build or extend web pages.

[unicomp21]

So there are code paths used infrequently (ie typically setup code), and there is code used frequently (ie tight loops doing computation). "If" we can "jit" the frequently used code paths from RiscV emulated instruction to native webassembly instructions, on the fly, for the "tight loop" cases mentioned above, we get the best of both worlds. Make sense?

Another thing to consider. While emulated instructions are definitely slower, what's even slower is L2/L3 cache-line misses. Having a "small" emulated instruction set, increases the chances of the "working set" staying within the L1 cache. CPU prefetch is also a very big deal, but this has more to do w/ how the application is written.

Long story short, there are multiple factors at play. But, I think we might have an easier/simpler path for getting the world to run "fast" on webassembly sitting right in front of us. And yes, all of this would be accessible by web pages.

[unicomp21]

Im not sure running your code inside a linux kernel which itself it running inside a CPU emulator is going to very practical

Take a look at jor1k, the bootup is crazy fast.

[unicomp21]

@kripken and others have been shouldering a herculean effort getting the C++ picture to where it is today, they are my heroes. I am simply hoping/trying to "reduce" their pain, and allow us to "get dramatically more for much less effort".

[tlively]

This is basically the approach taken by CheerpX. This approach is so different from what Emscripten does that it would not make sense for Emscripten to adopt it. It's super cool to see other projects experimenting with it, though!