3 ms·
> Startup time of any WASM program is going to be dominated by the fact that you're in the interpreter the whole time. The rest of your comment I agree with, b
by titzer 3y ago
> Startup time of any WASM program is going to be dominated by the fact that you're in the interpreter the whole time.
The rest of your comment I agree with, but this isn't really true. One of the advantages of engines/platforms like wasmtime is that they do indeed do AOT compilation and transparently cache JITed modules. Few Wasm runtimes have interpreters. So the fast startup that you get on the Fastly platform is primarily because Wasm modules are precompiled and instantiation has been heavily optimized.
I think overall that Wasm and containers solve mostly orthogonal problems, but there is some overlap in the serverless space. If programs are small and have few dependencies that can be inlined into a Wasm module, Wasm will do well against containers. If you have a very large software stack that has a lot of stuff in the container or base image, Wasm won't be as competitive; at least yet.
- mike_hearn 3y agoI suppose the question is why do the compilation server side? With a Linux sandbox policy as restrictive as WASI is, like by blocking all but a handful of syscalls, is there much difference between native machine code and WASM from the cloud operator perspective? Is maybe the issue here that low level Linux sandboxing with bpf and stuff isn't well documented, or maybe not trusted?
- titzer 3y agoFor one thing, Wasm gives CFI out of the box, so binaries you run are not vulnerable to RCE. Also, it's portable, so you can run on, e.g. arm servers.