Analyzing the Performance of WebAssembly vs. Native Code(ar5iv.labs.arxiv.org) |
Analyzing the Performance of WebAssembly vs. Native Code(ar5iv.labs.arxiv.org) |
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
so agreed, plugins. in games or in the kernel.
More discussion here https://github.com/moby/moby/issues/41389
But then it's hard to make sense of the idea that 300% slower is 5 items per hour (if I'm understanding correctly), since it works differently from "75% less than 20 is 5".
If I read "300% slower", I like to think about time, not speed.
300% more time = 400% original time = 4 times as long = 1/4 the speed
The key reason why applet security failed was because it gave you the entire JDK by default, and so every method in the JDK needed to have explicit security checking code in place to restrict access. The model was backwards -- full control by default with selective disabling meant that every new feature in the JDK is a new vulnerability.
Most of the later problems are due to the fact that the API attack surface was too large, because of the backwards SecurityManager design. And because it existed, it seems there was little incentive to do something better.
Once the instrumentation API was introduced (Java 5), it made it easier to write agents which could limit access to APIs using an "allow" approach rather than the awful rules imposed by the SecurityManager. Java 9 introduced modules, further hardening the boundaries between trusted and untrusted code. It was at this point the SecurityManager should have been officially deprecated, instead of waiting four more years.
Going back to the earlier comment, the problem isn't due to the runtime being somehow inherently insecure, but instead due to the defective design of the SecurityManager. It hasn't been necessary for providing security for many years.
Anyway, it's great if you compile it to Wasm.
Running code in a browser isn’t novel. It’s very circular. I actually met someone the other day that thought JavaScript was a subset of Java. Same person was also fluent in php.
Wasm is really neat, I really love it. My cynical take on it is that, at the end of the day, it’ll just somehow help ad revenue to find another margin.
Expanding margins are fine by me. Anticompetitive markets are not. My hope is that wasm helps to break a couple strangleholds over platforms (cough cough iOS cough Android)