[HN Gopher] Show HN: CheerpX - x86 Node.js/python3/Ruby REPL in ...
___________________________________________________________________
Show HN: CheerpX - x86 Node.js/python3/Ruby REPL in browser via
WebAssembly JIT
Author : apignotti
Score : 75 points
Date : 2021-01-05 14:46 UTC (8 hours ago)
(HTM) web link (repl.leaningtech.com)
(TXT) w3m dump (repl.leaningtech.com)
| ant6n wrote:
| Is it Possible to use this to put some Linux binary on a website?
| Is there a source/tutorial?
| apignotti wrote:
| 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...
| f1refly wrote:
| 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?
| oneearedrabbit wrote:
| 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.
|
| [0] https://github.com/iodide-project/pyodide/
|
| [1] http://diggyhq.com/
| apignotti wrote:
| 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.
| oneearedrabbit wrote:
| 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?
| apignotti wrote:
| 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.
| hint23 wrote:
| You can already do all that with https://bellard.org/jslinux
| yuri91 wrote:
| You can, but it is orders of magnitude slower.
|
| Try the "primes.js" example in the nodejs repl with CheerpX,
| then run it on jslinux and see for yourself.
|
| On my machine it runs about 600 times slower in jslinux than in
| CheerpX.
| classified wrote:
| How completely useless. The campaign to rewrite the universe in
| JS continues.
| [deleted]
| syrusakbary wrote:
| This is awesome!! Is CheerpX able to run the JITed code generated
| from node/v8 as well?
|
| Or said in other way: is the node binary compiled with v8 in
| interpreted mode, or does it support the v8 JIT?
| apignotti wrote:
| 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.
| syrusakbary wrote:
| WOW! That's incredible. Great work!
| hotd0g wrote:
| how do you install python libraries using this?
| vulcan01 wrote:
| 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.
|
| [0]: https://phet.colorado.edu [1]:
| https://www.leaningtech.com/pages/cheerpj.html
|
| (Not affiliated, just a very grateful student.)
| apignotti wrote:
| Happy to have been helpful :-)
| pbronez wrote:
| Pretty cool!
|
| 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
| apignotti wrote:
| 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.
| pbronez wrote:
| 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.
| apignotti wrote:
| (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.
| mbreese wrote:
| Not the Author, but I can hazard a few guesses...
|
| 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.
| pbronez wrote:
| > 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.
|
| [0] https://leaningtech.com/pages/cheerp.html
| dheera wrote:
| 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.
| pbronez wrote:
| 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....
| nynx wrote:
| Perhaps it's time to revisit jit extensions for webassembly [0].
|
| [0]:
| https://github.com/WebAssembly/design/blob/master/FutureFeat...
___________________________________________________________________
(page generated 2021-01-05 23:02 UTC)