3 ms·

A comparison between WASM and x86/ARM/etc native binaries is meaningful, because those are different formats for executable code. A comparison between WASM and

A comparison between WASM and x86/ARM/etc native binaries is meaningful, because those are different formats for executable code. A comparison between WASM and "containers" is meaningless, because the binaries being executed by a container runtime could be written in WASM. The executable format and the packaging format are separate concerns. This might be easier to think about if you imagine the article was written as "native code vs containers" -- what conclusions (if any) could you draw from the benchmarks in an article with that premise?

hansvm 3y ago
A comparison between WASM and "containers" is meaningful because in popular usage there's a cottage industry of WASM-based container solutions with the express goal (and co-evolved with the language to make this possible) of simplifying some of the thornier design decisions that make other containerization solutions easier to get started with (can just drop in any binary and dependencies) but also less performant for some set of tasks (have to set up network cgroups and other garbage). The phrase "WASM" isn't just being used to refer to the actual stack machine.
- jmillikin 3y ago
  WASM is WebAssembly. Words have meanings. If someone wants to try to advertise some weird custom platform that uses WASM as an intermediate bytecode for its packaging format then that's fine, but they'll need to pick a different name.
  - hansvm 3y ago
    WASI is a part of the WASM charter, and parts of WASM are explicitly designed to be friendly to such ideas; It's not quite _just_ some choice of bytecode. Besides, words are just approximations of thoughts, and even on the best of days the delineations aren't crisp. There's a critical mass of people using WASM+containers to refer to WASM ... plus containers (especially those built on the core tech supported by the WASM mission -- WASI -- like the platform tested in the article).
brabel 3y ago
Your argument is nonsense. It's like arguing that comparing the performance of an API that use lambdas VS a traditional API with an application running in the server is meaningless because "the lambda could be written in the application server". Who cares? If both can be used to implement the same API, the comparison is meaningful.
- jmillikin 3y ago
  Ok then. Let's say I write a webserver with WASI, compile it to a `.wasm` file, package it as an OCI container image, and deploy it in Kubernetes via a container runtime that loads the entry point into wasmtime. If containers and WASM are in fact competing technologies, as you and the article imply, then this shouldn't be possible. On the other hand, if WASM is a format for executable code as I claim, then packaging WASM as a container image and executing it in a container runtime is fine and should work as well as any other machine-independent bytecode (such as JVM).
  - brabel 3y ago
    WASM is a bytecode format like Java bytecode... the difference is that it's sandboxed. It can't do anything that's not explicitly given to it, including using WASI (the POSIX-like API for WASM code to "talk" to the system). Because it's sandboxed, you can use it without a container. I think that's what you don't seem to undestand. There are several companies offering WASM-based "containers" in the cloud - which don't need any actual container, the WASM runtime has the same type of capability of a container, to isolate processes running on the same hardware securely. It's even possible to make an actual Docker container run purely on a WASM runtime, as Docker itself is doing now! https://wasmlabs.dev/articles/docker-without-containers/ https://wasmlabs.dev/articles/docker-without-containers/
    - jmillikin 3y ago
      All bytecode is sandboxed by definition -- the VM decides which operations it delegates to the system. It is possible (and common!) to use JVM bytecode in a VM that restricts access to the underlying system, and in fact one of the original core use cases for Java (applets) relied on this functionality. The difference between WASM and JVM is that WASM was designed to be both (1) a compilation target for memory-unsafe languages like C, and (2) have verifiable control flow so it's easier to write a provably-secure JIT. > Because it's sandboxed, you can use it without a container. I think > that's what you don't seem to undestand. You don't seem to understand what a container is, or what a sandbox is. The reason to deploy software as a container image (instead of a standalone binary) is that a container image contains a full chroot, including auxiliary files that aren't embedded into the main binary. Whether the binary is native machine code or WASM doesn't matter -- the tradeoffs of bundling everything into one binary vs placing them on disk are the same regardless of executable format. The reason to run a sandbox is to restrict which system resources a process can access or interfere with. You can sandbox a process whether or not it runs in a container.

hansvm 3y ago

A comparison between WASM and "containers" is meaningful because in popular usage there's a cottage industry of WASM-based container solutions with the express goal (and co-evolved with the language to make this possible) of simplifying some of the thornier design decisions that make other containerization solutions easier to get started with (can just drop in any binary and dependencies) but also less performant for some set of tasks (have to set up network cgroups and other garbage). The phrase "WASM" isn't just being used to refer to the actual stack machine.

jmillikin 3y ago
WASM is WebAssembly. Words have meanings. If someone wants to try to advertise some weird custom platform that uses WASM as an intermediate bytecode for its packaging format then that's fine, but they'll need to pick a different name.
- hansvm 3y ago
  WASI is a part of the WASM charter, and parts of WASM are explicitly designed to be friendly to such ideas; It's not quite _just_ some choice of bytecode. Besides, words are just approximations of thoughts, and even on the best of days the delineations aren't crisp. There's a critical mass of people using WASM+containers to refer to WASM ... plus containers (especially those built on the core tech supported by the WASM mission -- WASI -- like the platform tested in the article).

brabel 3y ago

Your argument is nonsense. It's like arguing that comparing the performance of an API that use lambdas VS a traditional API with an application running in the server is meaningless because "the lambda could be written in the application server". Who cares? If both can be used to implement the same API, the comparison is meaningful.

jmillikin 3y ago
Ok then. Let's say I write a webserver with WASI, compile it to a `.wasm` file, package it as an OCI container image, and deploy it in Kubernetes via a container runtime that loads the entry point into wasmtime. If containers and WASM are in fact competing technologies, as you and the article imply, then this shouldn't be possible. On the other hand, if WASM is a format for executable code as I claim, then packaging WASM as a container image and executing it in a container runtime is fine and should work as well as any other machine-independent bytecode (such as JVM).
- brabel 3y ago
  WASM is a bytecode format like Java bytecode... the difference is that it's sandboxed. It can't do anything that's not explicitly given to it, including using WASI (the POSIX-like API for WASM code to "talk" to the system). Because it's sandboxed, you can use it without a container. I think that's what you don't seem to undestand. There are several companies offering WASM-based "containers" in the cloud - which don't need any actual container, the WASM runtime has the same type of capability of a container, to isolate processes running on the same hardware securely. It's even possible to make an actual Docker container run purely on a WASM runtime, as Docker itself is doing now! https://wasmlabs.dev/articles/docker-without-containers/ https://wasmlabs.dev/articles/docker-without-containers/
  - jmillikin 3y ago
    All bytecode is sandboxed by definition -- the VM decides which operations it delegates to the system. It is possible (and common!) to use JVM bytecode in a VM that restricts access to the underlying system, and in fact one of the original core use cases for Java (applets) relied on this functionality. The difference between WASM and JVM is that WASM was designed to be both (1) a compilation target for memory-unsafe languages like C, and (2) have verifiable control flow so it's easier to write a provably-secure JIT. > Because it's sandboxed, you can use it without a container. I think > that's what you don't seem to undestand. You don't seem to understand what a container is, or what a sandbox is. The reason to deploy software as a container image (instead of a standalone binary) is that a container image contains a full chroot, including auxiliary files that aren't embedded into the main binary. Whether the binary is native machine code or WASM doesn't matter -- the tradeoffs of bundling everything into one binary vs placing them on disk are the same regardless of executable format. The reason to run a sandbox is to restrict which system resources a process can access or interfere with. You can sandbox a process whether or not it runs in a container.