[HN Gopher] 152kb WebAssembly interpreter that runs on six OSs w...
___________________________________________________________________
152kb WebAssembly interpreter that runs on six OSs with
Cosmopolitan
Author : tambourine_man
Score : 236 points
Date : 2021-03-01 02:49 UTC (20 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| marmaduke wrote:
| maybe obvs to some, but if you're on a new fangled m1 big sur,
| you need to run this with chmod +x
| wasm3-cosmopolitan.com arch -x86_64
| ./wasm3-cosmopolitan.com
|
| and then go to preferences -> security -> run anyway, and then
| rerun it, then it works.
| vshymanskyy wrote:
| Author here. For Apple M1, I'd suggest building a native build
| of wasm3, to get full speed of "the fastest interpreter".
| 7373737373 wrote:
| I wish the WebAssembly page sizes wouldn't be fixed at 64kb, so
| even microcontrollers with very limited memory could use it
| MaxBarraclough wrote:
| Is WebAssembly a good fit for microcontrollers? Does it stack
| up well against Forth or its derivatives like [0]?
|
| [0]
| https://www.complang.tuwien.ac.at/anton/euroforth/ef13/paper...
| vshymanskyy wrote:
| The question is too generic. Wasm3 has some quirks when used
| directly on micro-controllers, and this is exactly why we're
| doing Wasm3 - to find if/how we can use it. For example,
| Linux uses eBPF for similar purposes. PAF could be used, as
| far as I can see. However WebAssembly will have some
| benefits: well-developed infrastracture, toolchains, language
| and tool support. Ability to run in browsers, etc.
| kbumsik wrote:
| I agree. 64kb is so small for modern PCs and browsers but it's
| still so big for microcontrollers that most of them can't
| afford it and is wasteful cosidering their application size.
| vshymanskyy wrote:
| Author here. In Wasm3, we have implemented some workarounds for
| that. We can easily run on Nordic nRF51 with just 16 KB of RAM!
| [deleted]
| ngcc_hk wrote:
| getting stream this line ... hope for more
| [deleted]
| danielEM wrote:
| This is not less portable and will beat any wasm interpreter in
| terms of speed: https://github.com/wwwg/wasmdec
| vshymanskyy wrote:
| But it requires Ahead-of-Time compilation, as well as full-
| fledge optimizing compiler. But for sure, this approach has
| it's own use cases.
| cassepipe wrote:
| Says it's 12 times slower than native execution... Does it mean
| some cpu can execute wasm directly? Please someone explain.
| k__ wrote:
| WebAssembly is a compilation target.
|
| Write C, compile to a native binary to get maximum speed,
| compile to WebAssembly and get maximum portability.
| [deleted]
| cesaref wrote:
| I interpret this as meaning if you take a native compiling
| project (say a C/C++ project) and benchmark this, then compile
| it to target wasm instead, it runs 1/12th of the speed of the
| native build.
| singularity2001 wrote:
| wasmer etc execute wasm almost directly: they do a (very)
| simple JIT transforming wasm to native assembly
| stagas wrote:
| Not sure of the details but it's an interpreter, so I believe
| it executes the wasm bytecode using its own VM, so there is
| overhead, where instead a compiler would generate optimized
| machine code linked with a wasm runtime for the target platform
| which can then be executed natively.
| diveanon wrote:
| Oh wow, I wonder how difficult it would be to embed this in
| database extensions.
|
| For example the PG wasm extension has kinda stalled, I would love
| to be build binaries for execution as db triggers and target
| wasm.
| Datagenerator wrote:
| ELI5 on Cosmopolitan (stack visualization if available)?
| bitwize wrote:
| Pretty much the binary format equivalent of that "single source
| file that compiles in C++/Pascal/Fortran/COBOL/shell/PHP"
| trick. While it's interesting in its own right, Hackernews
| currently thinks it's the future of computing.
| baq wrote:
| magic pixie dust for x86/amd64 executables which makes them run
| on bare metal, windows, linux, freebsd, ..., unchanged. it's a
| giant hack in the best possible meaning of the word.
| StavrosK wrote:
| I'm certainly doing the project a disservice with this, but
| isn't it "just" basically a file format hack that basically
| acts as an "if-check" that allows the executable to select an
| appropriate entry point depending on your OS?
| fctorial wrote:
| If checks are in the libc functions. (a guess, didn't look
| at the source)
| StavrosK wrote:
| It's more of a composite header (ELF/PE/etc) like those
| "it's both a JPG and a zip" things", though.
| fctorial wrote:
| Yes, that too.
| [deleted]
| Evidlo wrote:
| https://news.ycombinator.com/item?id=25556286
| IshKebab wrote:
| As I understand it (I haven't actually seen it explained
| anywhere). It's some kind of a hack that lets a single file be
| interpreted as both a shell script and a COM file, and a C
| library that does runtime detection of which OS you are
| running.
| ilaksh wrote:
| How does this do graphics? For th device demo is it using the
| framebuffer file like the other WASI demo?
| vshymanskyy wrote:
| We have some examples using pygame for image output. But it's
| not cosmopolitan-related. Check for pywasm3 python module.
| iovrthoughtthis wrote:
| Now do java.
| matheusmoreira wrote:
| JVMs probably have too many dependencies.
| ece wrote:
| OpenJDK was ported to musl libc[1], so I guess Cosmopolitan
| should be possible, musl is a lot smaller than glibc. I'd
| also like to see how well RISC-V is supported by Cosmpolitan.
|
| [1] https://openjdk.java.net/jeps/386
| yholio wrote:
| Am I missing something or is the work required to write an
| interpreter comparable to the work involved in a drop-dead-simple
| compiler, that even without any optimizations is guaranteed to be
| faster? The wasm instruction set maps very well over the x86_64
| instructions, you already need to build a decoder for the input
| binary, so with a bit more glue code and address space setup you
| can execute wasm directly. More complex functions and
| instructions can fallback to the precompiled versions that you
| have to write anyway.
|
| But again, there might be complexity I'm missing.
| flohofwoe wrote:
| The readme has a small section about the interpreter vs JIT
| tradeoffs:
|
| https://github.com/wasm3/wasm3#motivation
|
| Also, maybe the "Cosmopolitan platform abstraction" doesn't
| support mapping memory pages and making them executable, which
| would be required for a JIT (speculating, I haven't actually
| checked).
| yholio wrote:
| So they are not targeting just x86_64 like here, but also
| MIPS, various MCUs, iOS and even wasm itself. Yeah, that will
| get hairy in a hurry.
| murkle wrote:
| This link is better as it actually explains what it is/does
| https://github.com/wasm3/wasm3
| vshymanskyy wrote:
| Fixed the description, thanks!
| fctorial wrote:
| I think the emphasis is on cosmopoliton here. It's a cross
| platform c runtime + a cross platform exe format == cross
| platform binaries.
| murkle wrote:
| Neither link mentions / links that. Do you mean
| https://justine.lol/cosmopolitan/index.html ?
| user-the-name wrote:
| The first page has a link to download
| wasm3-cosmopolitan.com.
| esperent wrote:
| > 4-5x slower than state of the art wasm JIT engines
|
| Does that mean browser engines?
| emteycz wrote:
| I believe V8 is state of the art, with Gecko and then
| Cranelift behind it.
| chrismorgan wrote:
| I understand that Firefox is on average faster than Chrome
| at WASM, though there are plenty of tests where either is
| faster than the other.
|
| However, I can't find much actual qualitative performance
| comparison of Firefox (there's a little more of V8).
|
| A couple that I have found are
| https://www.usenix.org/conference/atc19/presentation/jangda
| (from almost two years ago), showing Firefox being about
| 20% faster than Chrome:
|
| > _Across the SPEC CPU suite of benchmarks, we find a
| substantial performance gap: applications compiled to
| WebAssembly run slower by an average of 45% (Firefox) to
| 55% (Chrome), with peak slowdowns of 2.08x (Firefox) and
| 2.5x (Chrome)._
|
| And https://github.com/wasm3/wasm3/blob/master/docs/Perform
| ance.... of CoreMark 1.0 (higher is better), showing
| Firefox being about 5% faster than Chromium:
| Webassembly.sh (Chromium 78) 6914.325225 4.2x
| Webassembly.sh (Firefox 70) 7251.153593 4.5x
| himujjal wrote:
| wasm3 is slow for a reason actually. Its meant for IoT
| devices rather than full fledged PCs
| amelius wrote:
| If it's slower, then perhaps it's more secure? (I.e., less
| optimizations that can have bugs)
| ghusbands wrote:
| If it's slow due to being simpler, that simplicity will
| probably lead to fewer bugs, indeed.
|
| If it's slow for other reasons, there'd be no clear
| correlation.
| maxgraey wrote:
| latest benchmarks with wasm3, wasmer, wasmtime, wavm and etc:
| https://www.00f.net/2021/02/22/webassembly-runtimes-benchmar...
| oblio wrote:
| This Cosmopolitan thing for sure opened some floodgates :-)
|
| It's a shame that I imagine OS vendors will find some fancy ways
| to make it at least annoying to use it, in at most a few years. I
| think it's already happening, with code signing/notarization.
| DerWOK wrote:
| suggested to tag cosmopolitan projects with such a cosmopolitan
| tag https://github.com/wasm3/wasm3/issues/205
| adkadskhj wrote:
| Cosmopolitan is this i assume?:
| https://justine.lol/cosmopolitan/index.html
|
| So related to the whole https://justine.lol/ape.html crazy.
| Neat!
| 1996 wrote:
| Just think about the saved costs: only 1 binary, so only 1
| notarization to pay for!
___________________________________________________________________
(page generated 2021-03-01 23:03 UTC)