I'm more interested in 1) usages of wasm in the browser that don't involve running unmodified unix programs and 2) wasm outside the browser for compile-once-run-anywhere usecases with sandboxing / security guarantees. Could it be the future for writing native applications?
Languages like Kotlin, C#, Rust, as well as C/C++ etc support wasm quite well. Could we see that be a legitimate target for applications in the future, if the performance gap was closer to 10%-ish? I would personally prefer running wasm binaries with guaranteed (as much as possible ofc) sandboxing compared to raw binaries.
edit: it's from 2019, there have been significant improvements made to wasm since then.
I've been using it this way for DecentAuth[0]. It's awesome. I compile a single native codebase to wasm, and I can use my library from JS, Go, or Rust. New host languages only require about 1000 lines of glue. I don't have to worry at all about building for different architectures.
Please just use Docker in a microVM or whatever. It's 0% slower and 100% more mature.
Wasm has different characteristics than docker containers and as a result can target different use cases and situations. For example, Imagine needing plugins for game mods or an actor system, where you need hundreds of them or thousands, with low latency startup times and low memory footprints and low overheads. This is something you can do sanely with wasm but not with containers. So containers are great for lots of things but not every conceivable thing, there’s still a place for wasm.
And also, it's not necessarily apples to apples. It would be nice to be able to drop a compiled WASM module into your codebase and use it from just about any language on the backend. You could reuse a lot of code that way across different services without the overhead of spinning up yet another container. And you could potentially even run untrusted code in a sandboxed way.
https://stackoverflow.com/questions/60840320/docker-50-perfo...
2019 (250 points, 172 comments) https://news.ycombinator.com/item?id=20458173
2020 (174 points, 205 comments) https://news.ycombinator.com/item?id=19023413
I'll take that deal any day!
“Wait we can use Java to run anywhere? It’s slow but that’s ok! Let’s ride!”
Also, targeting the JVM forces you to accept garbage collection, class-based OO and lots of pointer chasing. It's not a good target for most languages.
Java's pretty good, but wasm is actually a game changer.
Its definitely a good deal!
Undefined behaviour is defined with respect to the source language, not the execution engine. It means that the language specification does not assign meaning to certain source programs. Machine code (generally) doesn't have undefined behaviour, while a C program could, regardless of what it runs on.
Suppose native code takes 2 units of time to execute.
“45% slower” is???
Would it be 45% _more time?_
What would “45% _faster_” mean?
(I think I would generally use "x% slower" to mean "slower by a factor of 1+x/100", and "x% faster" to mean "faster by a factor of 1+x/100", so "x% slower" and "x% faster" are not inverses, you can perfectly well be 300% faster or 300% slower, etc. I less confidently think that this is how most people use such language.)
If the original process took 30 minutes to process 10 items, how long would the 300% faster method take?
I think it is easier to understand in terms of throughput.
So 45% less work per unit of time, so 55% of the work.
10% slower means "takes 10% longer." 10% more seconds.
So 45% slower than 2 seconds is 1.45 * 2 = 2.9 seconds.
At least for cryptography, WebAssembly can be very slow and can hardly provide any guarantee against side channels.
I think vectorization support will narrow the aggregate difference here as a lot of SPEC benefits from auto vectorization if I recall correctly.
The title is highly misleading.
But as already mentioned we have gone through this all before. Maybe we'll see wasm bytecodes pushed through silicon like we did the Jvm... Although perhaps this time it might stick or move up into server hardware (which might have happened, but I only recall embedded devices supporting hardware level Jvm bytecodes).
In short the web browser bit is omitted from the title.
Initially slower but then faster after full compilation