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