What are the tradeoffs of running virtualized x86 in the browser via WASM relative to a traditional VM (e.g. Virtual Box) or VM-like container runtime like Firecracker [0]? I would expect to get improved portability (it's a webpage) at the cost of some performance and security.
The ShowHN link is for the REPL demo, the actual homepage for the CheerpX x86 to WASM virtualizer is here [1]
Minor bug: when you load a new REPL, the loading log fills the screen and continues below the fold without auto-scolling to keep up with new output. You have to manually scroll past a list of all the component modules to see the new REPL.
Running this in the browser makes for a ridiculously easy setup. You can get up and running very quickly by just giving someone a URL (probably with a pre-unpacked image). Setting up a VM on the other hand, can be daunting if you don't already have the infrastructure setup. This might be a benefit of running this WASM VM vs a local VM.
Second, you get the security benefit of running the code on your local computer as opposed to a remote VM. This may not be a big issue, but for some circumstances, it could be.
Third, by running it locally as opposed to on a remote VM, might be more interactive, in that you don't have the round-trip time client -> server -> client. But this depends on how performant the WASM VM is.
This isn't something you do for performance. The WASM VM seems "fast enough", but this isn't something that will be faster than many cloud-based VMs. For me, the major benefits would be setup/maintenance and security.
Personally find this to be a pretty cool project, but I'm not sure of where I'd use it outside of teaching... but it's quite impressive.
For the scrolling -- I found that once I scrolled to the bottom once, it auto-scrolled. But I was confused when I unpacked Python by this too.
> Running this in the browser makes for a ridiculously easy setup. You can get up and running very quickly by just giving someone a URL (probably with a pre-unpacked image)... I'm not sure of where I'd use it outside of teaching... but it's quite impressive.
Teaching seems like a great use case. Maybe they'll use similar licensing as their Cheerp compiler [0] and provide a basic community tier. You could give students a foolproof (?) way to run a controlled set of applications locally without the confusion of setting up a local VM host or the expense of hosting virtual machines for the class. That assumes your students have decent computers.
Actually, this would be a nice way to sideload real applications onto Chromebooks. Certainly more secure/accessible/maintainable than unlocking all the default protections and side-loading Linux first.
The company has already donated their technology and time to emulating educational Java apps under WASM, which is helpful for school districts that are Chromebook-only.
The tradeoff is only some performance, there is no security risk. CheerpX used standard WebAssembly/JavaScript/HTML5, there is truly no difference between this and any other Web page you might visit.
The scrolling behavior you mentioned is actually a feature, we want to give people time to read the first message before filling up the console.
Hi Alessandro - amazing work on this & thanks for the reply. This is the coolest WASM demo I've seen since the first Emscripten release. Moving WASM execution from a compile-time choice to a runtime choice is pretty amazing. I need to noodle on the implications of the portability benefits.
> The tradeoff is only some performance, there is no security risk. CheerpX used standard WebAssembly/JavaScript/HTML5, there is truly no difference between this and any other Web page you might visit.
I understand that the security model is more like a webpage than a local binary. What I don't understand is:
(1) what is the relative difficulty of escaping a full, local VM vs a local browser sandbox vs microVM container? That is, if you want to run an untrusted x86 binary locally, is CheerpX + browser sandbox really as safe as VirtualBox or firecracker? I suspect there's a speed/security tradeoff happening somewhere.
(2) how complete is the set of operating system APIs available to an x86 running in WASM via CheerpX vs running that same application locally? That is, what local functionality might I sacrifice to use the browser?
(3) what is the nature and magnitude of the performance hit? Obviously you have to load the binary over the network in this demo, but locally-hosted resources should be fine.
(1) I am not sure I understand the question. It seems to me that it really boils down to "Do you trust the browser to run arbitrary code?" There is truly no way for CheerpX to do anything more than what your average Web page could do.
(2) We are implementing syscalls and devices as they are needed for the various use cases we are considering. In general even if something is not natively supported in the browser it can still be virtualized to various degrees. In particular CheerpX provides a virtualized FileSystem that does not map to your local files. The same would apply for the virtual disks in traditional VMs though.
(3) We plan to release benchmarks soon, but the level of performance is very promising. Consider that we have been using the Flash plugin as our main benchmark which is very demanding. For the REPL use case the limiting factor right now is I/O performance, but we are already working on this and we thing we will achieve much better results very soon. In general, all aspects of CheerpX performance will improve, we are really not done yet.
Virtualized x86 in the browser doesn't get anywhere near the performance of a traditional VM that is doing kernel-level virtualization. Also, your VM images will be huge for most software packages that do anything useful.
The upside is obvious, it's idiot-proof and zero setup.
Any thoughts on a simple way to benchmark that? I suppose it'd be easy enough to time some python scripts in the hosted REPL against local execution....
This is a surprisingly common question. What you see is a standard node.js/V8 package from Ubuntu with no modification at all. V8 will emit JIT x86 code that will be then further JITted into Wasm if hot enough.
I just want to point out that the same company also partners with the University of Colorado's PhET [0], to run their old Java simulations in the browser using another one of their products.
It feels a bit off-topic, but I could not resist giving a shout-out to Pyodide [0] which brings CPython and SciPy stack to WASM world. It works reasonably fast once the runtime is cached in your browser, and then takes roughly 3-5 seconds to initialize a complete Python environment in the browser (at least this is what it takes on my antique Macbook).
CheerpX is more advanced in a way that you can run arbitrary binaries. I’m interested to learn more about the performance tradeoffs and compare benchmarks. Out of curiosity, what’s your take on libraries that require compilation step, e.g. Pandas/NumPy?
What I particularly like about WASM is you don’t need to install anything on your machine. It’s as simple as clicking a link, and you have a secure environment that works right out of the box.
On a more personal note, I was excited about Pyodide, and about a month ago I began developing a visual notebook. Its initial purpose was to create a Python playground, which can render ad-hoc visualizations into a browser to share them with my friends. Zero setup, just type some Python code in the browser and instantly see results, render charts, etc. [1]
Overall, I love the momentum that erases the setup step for traditional tools, ultimately bringing joy to programming. I believe it would be a great way to introduce programming concepts in an educational setting.
Libraries with a binary component will work as expected with our approach. CheerpX runs arbitrary x86 code, there is nothing special about Python in particular.
Obviously compiling directly to Wasm will provide the best level of performance, but it also take effort for every single application/library you want to port.
Thanks! On a technical side, do you run the whole application in the main thread of a web worker. I wonder whether you considered using service workers for the faster boot up?
I don't think service workers would help in this case. As mentioned elsewhere we are working on a revamp of the I/O subsystem that should significantly improve startup time already.
CheerpX is not yet released to the public for the arbitrary Linux application use case. We plan to do so, but at this time we are fully focused on the CheerpX for Flash use case, for obvious timing reasons: https://medium.com/leaningtech/cheerpx-for-flash-now-general...
Can we maybe, at some point, all agree that we can now stop putting more parts of the operating system into the browser? Aside from the tech demo aspect (which is moot imo, since webassembly is obviously capable of everything regular assembly would be), why would anyone want to run a binary inside the webbrowser in a virtual javascript machine that he could just run on the regular machine anyways?
What are the tradeoffs of running virtualized x86 in the browser via WASM relative to a traditional VM (e.g. Virtual Box) or VM-like container runtime like Firecracker [0]? I would expect to get improved portability (it's a webpage) at the cost of some performance and security.
The ShowHN link is for the REPL demo, the actual homepage for the CheerpX x86 to WASM virtualizer is here [1]
Minor bug: when you load a new REPL, the loading log fills the screen and continues below the fold without auto-scolling to keep up with new output. You have to manually scroll past a list of all the component modules to see the new REPL.
[0] https://firecracker-microvm.github.io/
[1] https://leaningtech.com/pages/cheerpx.html