4 ms·

Wasmtime 1.0: A Look at Performance

99 points by mnemonik 4y ago

jedisct1 4y ago
Probably a good time to run a new iteration of the Libsodium WebAssembly benchmarks.
jeroenhd 4y ago
How 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?
- dadoum 4y ago
  > 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-webassembly/ https://hacks.mozilla.org/2020/02/securing-firefox-with-weba...
  - 3836293648 4y ago
    Firefox is weird. The compile to wasm and then aot-compile that to native code. It's purely to get C/C++ boundschecking and stuff like that everywhere
- klabb3 4y ago
  > 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)
  - felixgallo 4y ago
    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?
    - mort96 4y ago
      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.
      - klabb3 4y ago
        Indeed, not to mention the GC, which isn't one size fits all (not even within Java itself). And wasm could run in ring 0 if you want, the runtime is that hardened.
        miohtama 4y ago
        You can “already” run Wasm modules in kernel to speed up things https://github.com/wasmerio/kernel-wasm https://github.com/wasmerio/kernel-wasm
    - phickey 4y ago
      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.
- mort96 4y ago
  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.
  - jeroenhd 4y ago
    > 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. Isn't that exactly what Java did years ago? And what Microsoft's .NET bytecode did when they had to remove the Microsoft JVM? Standard WASM is stack based, unlike every real computer out there. It also explicitly supports unaligned memory which is terrible for native execution performance. It was designed for the limitations of the browser sandbox as an evolution on a backwards compatible Javascript library. I don't know why you'd need tk shop different versions for different instruction sets, that's exactly the problem Java, and to a lesser extent dotnet, solves. The runtime is platform dependent, the binary isn't. You can build a JAR and run it on anything from old MIPS server to a Windows 11 machine or an M2 Mac if your code targets a runtime old enough. You don't need to compile separate versions for each platform at all. Building platform independent executables has already been solved by Java and very few people actually use it. I'm not against an alternative to Java, or anything else tainted by Oracle for that matter, I just don't see the use cases outside the browser for platforms precompiling WASM.
stevemk14ebr 4y ago
It is very disappointing there are no embeddable, performant wasm runtimes. The language is perfect for embedded systems, it's a near asm level sandbox. But there's no good no_std or limited dependency runtimes! If wasm is to grow, it should work on this use case. I should be able to provide platform APIs to allocate memory, maybe do some floating point math, and then that's about it. Additional features would just be giving some additional API implementations the runtime needs to interact with the host machine. Context: this was a huge barrier for me on my project https://github.com/mandiant/STrace/blob/16859a811e4af7c68259949ef94a4ed3ed41beec/blog/Script.txt#L95 https://github.com/mandiant/STrace/blob/16859a811e4af7c68259...
- CharlesW 4y ago
  Have you looked at WebAssembly Micro Runtime (WAMR)? https://github.com/bytecodealliance/wasm-micro-runtime https://github.com/bytecodealliance/wasm-micro-runtime
- skyde 4y ago
  are you talking about something similar to micropython for micro controller?
- jedisct1 4y ago
  wasm3 is super small and easy to embed.
fwsgonzo 4y ago
Happy to see they finally reduced the instantiation time to a few microseconds. I have had 1 micro in prod for another emulator, so I was wondering what the holdup was. Also see they are using madvise for CoW - it is fairly slow and I ended up not using it. That is, pagetable changes on Linux are just absolutely unusably slow on a larger scale, in production.

99 points by mnemonik 4y ago

Probably a good time to run a new iteration of the Libsodium WebAssembly benchmarks.

How 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?

dadoum 4y ago
> 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-webassembly/ https://hacks.mozilla.org/2020/02/securing-firefox-with-weba...
- 3836293648 4y ago
  Firefox is weird. The compile to wasm and then aot-compile that to native code. It's purely to get C/C++ boundschecking and stuff like that everywhere
klabb3 4y ago
> 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)
- felixgallo 4y ago
  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?
  - mort96 4y ago
    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.
    - klabb3 4y ago
      Indeed, not to mention the GC, which isn't one size fits all (not even within Java itself). And wasm could run in ring 0 if you want, the runtime is that hardened.
      - miohtama 4y ago
        You can “already” run Wasm modules in kernel to speed up things https://github.com/wasmerio/kernel-wasm https://github.com/wasmerio/kernel-wasm
  - phickey 4y ago
    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.
mort96 4y ago
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.
- jeroenhd 4y ago
  > 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. Isn't that exactly what Java did years ago? And what Microsoft's .NET bytecode did when they had to remove the Microsoft JVM? Standard WASM is stack based, unlike every real computer out there. It also explicitly supports unaligned memory which is terrible for native execution performance. It was designed for the limitations of the browser sandbox as an evolution on a backwards compatible Javascript library. I don't know why you'd need tk shop different versions for different instruction sets, that's exactly the problem Java, and to a lesser extent dotnet, solves. The runtime is platform dependent, the binary isn't. You can build a JAR and run it on anything from old MIPS server to a Windows 11 machine or an M2 Mac if your code targets a runtime old enough. You don't need to compile separate versions for each platform at all. Building platform independent executables has already been solved by Java and very few people actually use it. I'm not against an alternative to Java, or anything else tainted by Oracle for that matter, I just don't see the use cases outside the browser for platforms precompiling WASM.

stevemk14ebr 4y ago

It is very disappointing there are no embeddable, performant wasm runtimes. The language is perfect for embedded systems, it's a near asm level sandbox. But there's no good no_std or limited dependency runtimes! If wasm is to grow, it should work on this use case. I should be able to provide platform APIs to allocate memory, maybe do some floating point math, and then that's about it. Additional features would just be giving some additional API implementations the runtime needs to interact with the host machine. Context: this was a huge barrier for me on my project https://github.com/mandiant/STrace/blob/16859a811e4af7c68259949ef94a4ed3ed41beec/blog/Script.txt#L95 https://github.com/mandiant/STrace/blob/16859a811e4af7c68259...

CharlesW 4y ago
Have you looked at WebAssembly Micro Runtime (WAMR)? https://github.com/bytecodealliance/wasm-micro-runtime https://github.com/bytecodealliance/wasm-micro-runtime
skyde 4y ago
are you talking about something similar to micropython for micro controller?
jedisct1 4y ago
wasm3 is super small and easy to embed.

fwsgonzo 4y ago

Happy to see they finally reduced the instantiation time to a few microseconds. I have had 1 micro in prod for another emulator, so I was wondering what the holdup was. Also see they are using madvise for CoW - it is fairly slow and I ended up not using it. That is, pagetable changes on Linux are just absolutely unusably slow on a larger scale, in production.