Wasmtime 1.0: A Look at Performance
bytecodealliance.org
Wasmtime 1.0: A Look at Performance
1–10 of 23 posts
Re: Wasmtime 1.0: A Look at Performance
#2Probably a good time to run a new iteration of the Libsodium WebAssembly benchmarks.
Re: Wasmtime 1.0: A Look at Performance
#3How do bytecode compilers like Cranelift compare to native images generated out of bytecode that's easier to optimize for pure machine code execution (Java, dotnet)?
Perhaps more relevant: what's the point of taking machine code capable software, compiling it into WASM, and then compiling that back into machine code? A reinvention of FFI perhaps?
Re: Wasmtime 1.0: A Look at Performance
#4How do bytecode compilers like Cranelift compare to native images generated out of bytecode that's easier to optimize for pure machine code execution (Java, dotnet)? Perhaps more relevant: what's the point of taking machine code capable software, compiling it into WASM, and then compiling that back into machine code? A reinvention of FFI perhaps?
> Perhaps more relevant: what's the point of taking machine code capable software, compiling it into WASM, and then compiling that back into machine code? A reinvention of FFI perhaps?
Firefox has some parts which are compiled to WebAssembly, and Mozilla wrote an article about it [0]. They seem to use WebAssembly to sandbox the code and improve security.
[0]: https://hacks.mozilla.org/2020/02/securing-firefox-with-weba...
Re: Wasmtime 1.0: A Look at Performance
#5How do bytecode compilers like Cranelift compare to native images generated out of bytecode that's easier to optimize for pure machine code execution (Java, dotnet)? Perhaps more relevant: what's the point of taking machine code capable software, compiling it into WASM, and then compiling that back into machine code? A reinvention of FFI perhaps?
> what's the point of taking machine code capable software, compiling it into WASM, and then compiling that back into machine code?
If I understand your question correctly, the point is that wasm becomes the agreed-upon target, so you only need language -> wasm compilation and you can then distribute that artifact everywhere. Then you can either JIT it or recompile it into machine code at the endpoint, as an optimization.
That would help reduce the size of the graph of N languages and M architectures from O(MN) to O(M+N) (similar to the function of IR)
Re: Wasmtime 1.0: A Look at Performance
#6How do bytecode compilers like Cranelift compare to native images generated out of bytecode that's easier to optimize for pure machine code execution (Java, dotnet)? Perhaps more relevant: what's the point of taking machine code capable software, compiling it into WASM, and then compiling that back into machine code? A reinvention of FFI perhaps?
> what's the point of taking machine code capable software, compiling it into WASM, and then compiling that back into machine code? If I understand your question correctly, the point is that wasm becomes the agreed-upon target, so you only need language -> wasm compilation and you can then distribute that artifact everywhere. Then you can either JIT it or recompile it into machine code at the endpoint, as an optimiza…
why would any language besides javascript want to be that maximalist, when they already have either a much better direct native compiler, or their own, purpose-built, mechanically-sympathetic, fully featured interpreter with first-class support and a controllable destiny? We didn't do this with Java back in the day when it was possible -- essentially all but a small handful of JVM languages died on the vine -- so what specifically is different this time?
Re: Wasmtime 1.0: A Look at Performance
#7How do bytecode compilers like Cranelift compare to native images generated out of bytecode that's easier to optimize for pure machine code execution (Java, dotnet)? Perhaps more relevant: what's the point of taking machine code capable software, compiling it into WASM, and then compiling that back into machine code? A reinvention of FFI perhaps?
Ignoring security for a moment: Say you want to write a web application in Rust. You want to ship your web application to your users. You don't want your users to have to wait for the whole application to compile and download all dependencies; you want to ship some precompiled stuff. What do you ship?
We could have some web standard where we ship native code to the user, which the user's machine then executes directly (using some form of sandboxing). Maybe we could have a standard API so that the operating system's interfaces don't play a role. But you still have to ship x86_64, aarch64, ARM32, RISC-V 32, RISC-V 64, MIPS, PowerPC, etc. And you'll need to support multiple versions of all these different instruction sets; some users may have old x86 machines without SSE, so you need a version of your x86 code with x87 floats rather than SSE floats. And you need one version of your ARM native code with hard floats for machines with FPUs, and one version with soft floats for machines without. And you need to constantly add new variations as new instruction sets or new versions of old instruction sets are released.
I don't trust most websites to get all of this correct. And if websites got it wrong, or if websites ever stopped adding new targets, or ever removed supports for old targets, we would end up with a web which isn't usable on certain CPU architectures, which is the opposite of what the web is all about.
The alternative is that we have some specification for intermediate code which is low level enough to be a universal compile target but abstract enough to be possible to compile to essentially any CPU architecture. That's what WASM is.
Re: Wasmtime 1.0: A Look at Performance
#8Earlier quoted context omitted.
> what's the point of taking machine code capable software, compiling it into WASM, and then compiling that back into machine code? If I understand your question correctly, the point is that wasm becomes the agreed-upon target, so you only need language -> wasm compilation and you can then distribute that artifact everywhere. Then you can either JIT it or recompile it into machine code at the endpoint, as an optimiza…
why would any language besides javascript want to be that maximalist, when they already have either a much better direct native compiler, or their own, purpose-built, mechanically-sympathetic, fully featured interpreter with first-class support and a controllable destiny? We didn't do this with Java back in the day when it was possible -- essentially all but a small handful of JVM languages died on the vine -- so wha…
JVM bytecode is, to my understanding, basically just a serialized, desugared Java. It has a concept of classes with constructors and it has objects and references and inheritance and basically all of Java's semantics encoded in it. Languages which aren't "java-like" have a hard time compiling to it. WASM, on the other hand, is more like machine code, so languages which are used to compiling to machine code have a fairly easy time compiling to it.
Re: Wasmtime 1.0: A Look at Performance
#9Earlier quoted context omitted.
> what's the point of taking machine code capable software, compiling it into WASM, and then compiling that back into machine code? If I understand your question correctly, the point is that wasm becomes the agreed-upon target, so you only need language -> wasm compilation and you can then distribute that artifact everywhere. Then you can either JIT it or recompile it into machine code at the endpoint, as an optimiza…
why would any language besides javascript want to be that maximalist, when they already have either a much better direct native compiler, or their own, purpose-built, mechanically-sympathetic, fully featured interpreter with first-class support and a controllable destiny? We didn't do this with Java back in the day when it was possible -- essentially all but a small handful of JVM languages died on the vine -- so wha…
The security properties are ultimately why we invested in WebAssembly. We (Fastly; the author is my colleague) run very large numbers of WebAssembly modules, all in the same process where the plaintext HTTP requests and responses from very large numbers of our customers reside, without needing to trust the authors of those modules. There are many technologies for running untrusted code out there, and we picked WebAssembly because we can make it fast in all the ways this article details without compromising on security.
Stay tuned, the next article in this series on Wasmtime security will run next Tuesday.
Re: Wasmtime 1.0: A Look at Performance
#10Earlier quoted context omitted.
why would any language besides javascript want to be that maximalist, when they already have either a much better direct native compiler, or their own, purpose-built, mechanically-sympathetic, fully featured interpreter with first-class support and a controllable destiny? We didn't do this with Java back in the day when it was possible -- essentially all but a small handful of JVM languages died on the vine -- so wha…
The security properties are ultimately why we invested in WebAssembly. We (Fastly; the author is my colleague) run very large numbers of WebAssembly modules, all in the same process where the plaintext HTTP requests and responses from very large numbers of our customers reside, without needing to trust the authors of those modules. There are many technologies for running untrusted code out there, and we picked WebAss…
> all in the same process where the plaintext HTTP requests and responses from very large numbers of our customers reside
The security of this looks very very fragile. Practically any vulnerability may leave the requests of all customers unprotected.
Compare with the common practice of isolating each customer on its own address space or, better yet, on their own VM, requiring a privilege escalation vulnerability (which is much rarer) to eveasdrop on other processes or VMs running on the same computer
edit: now, if you're running each wasm module on a separate process, sandboxed with seccomp-bpf, now that's another thing entirely, and might be more secure AND more performant than traditional VMs