152kb WebAssembly interpreter that runs on six OSs with Cosmopolitan | Hacker News Reader

152kb WebAssembly interpreter that runs on six OSs with Cosmopolitan

github.com

252 pointstambourine_man52 comments

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.

suggested to tag cosmopolitan projects with such a cosmopolitan tag https://github.com/wasm3/wasm3/issues/205

Just think about the saved costs: only 1 binary, so only 1 notarization to pay for!

Cosmopolitan is this i assume?: https://justine.lol/cosmopolitan/index.html

So related to the whole https://justine.lol/ape.html crazy. Neat!

This link is better as it actually explains what it is/does https://github.com/wasm3/wasm3

> 4-5x slower than state of the art wasm JIT engines

Does that mean browser engines?

I believe V8 is state of the art, with Gecko and then Cranelift behind it.

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.08× (Firefox) and 2.5× (Chrome).

And https://github.com/wasm3/wasm3/blob/master/docs/Performance.... 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

wasm3 is slow for a reason actually. Its meant for IoT devices rather than full fledged PCs

If it's slower, then perhaps it's more secure? (I.e., less optimizations that can have bugs)

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.

I think the emphasis is on cosmopoliton here. It's a cross platform c runtime + a cross platform exe format == cross platform binaries.

Neither link mentions / links that. Do you mean https://justine.lol/cosmopolitan/index.html ?

The first page has a link to download wasm3-cosmopolitan.com.

Fixed the description, thanks!

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.

Author here. For Apple M1, I'd suggest building a native build of wasm3, to get full speed of "the fastest interpreter".

Alternatively, add Terminal.app to the Privacy -> Developer Tools option (this may require installing Xcode), which allows processes it starts to bypass Gatekeeper. It won't solve the arch problem, but it'll get around the second part.

I wish the WebAssembly page sizes wouldn't be fixed at 64kb, so even microcontrollers with very limited memory could use it

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.

Author here. In Wasm3, we have implemented some workarounds for that. We can easily run on Nordic nRF51 with just 16 KB of RAM!

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...

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.

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.

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).

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.

latest benchmarks with wasm3, wasmer, wasmtime, wavm and etc: https://www.00f.net/2021/02/22/webassembly-runtimes-benchmar...

Says it's 12 times slower than native execution... Does it mean some cpu can execute wasm directly? Please someone explain.

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.

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.

wasmer etc execute wasm almost directly: they do a (very) simple JIT transforming wasm to native assembly

WebAssembly is a compilation target.

Write C, compile to a native binary to get maximum speed, compile to WebAssembly and get maximum portability.

This is not less portable and will beat any wasm interpreter in terms of speed: https://github.com/wwwg/wasmdec

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.

How does this do graphics? For th device demo is it using the framebuffer file like the other WASI demo?

We have some examples using pygame for image output. But it's not cosmopolitan-related. Check for pywasm3 python module.

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.

ELI5 on Cosmopolitan (stack visualization if available)?

https://news.ycombinator.com/item?id=25556286

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.

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.

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?

If checks are in the libc functions. (a guess, didn't look at the source)

It's more of a composite header (ELF/PE/etc) like those "it's both a JPG and a zip" things", though.

Yes, that too.

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.

Indeed. I am sincerely confused as to why people are so enamored with this.

Now do java.

JVMs probably have too many dependencies.

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

> I'd also like to see how well RISC-V is supported by Cosmpolitan.

Not at all. The whole idea is based on limiting your outlook to x86_64. So, Cosmopolitan is definitely cool, but a bit less cool than some people think.

getting stream this line ... hope for more

Reply on news.ycombinator.com