4 ms·

I mostly agree with you, but I think I can shed some light here: > As programs get larger they do things like load config files, connect to databases, initiali

by paulgb 3y ago

I mostly agree with you, but I think I can shed some light here: > As programs get larger they do things like load config files, connect to databases, initialize in-memory caches, possibly reflect themselves because that's often convenient, and so on. Because it's all init code none of this is hot, so it gets interpreted and that's slow. One of the most interesting aspects of Wasm is that because it is built with isolation in mind, it's really easy to get a snapshot and run it later. So instead of doing all the cache initialization etc. at init time, you can initialize the module at build time and then take a snapshot of it for a very quick cold start next time. When running in the browser, there is still an initialization step to process the wasm bytecode, but in the server-side world this can also be done in advance since you can trust the compiler and know in advance which processor architecture you will want to run it on.

mike_hearn 3y ago
Right, but that trick also isn't new. emacs was doing it decades ago and there are JVMs that also do it. That's how GraalVM native images can start and run faster than C programs do: the app is initialized at build time and then the state is just mmapped into a pre-compiled native process. HotSpot has a less aggressive version of this where you can pre-initialize a lot of VM state and dump it to a file for faster startup time. It's about a 30% win and that's going up over time, but it doesn't AOT compile everything. Of course, if you're serious about instant startup from zero then you end up going the native-image route, but then what value is WASM adding? What's being shipped to the edge in that case is a compiled binary anyway. There is some scope here for threading the needle - for example, an edge worker implementation could be given compiled bytecode of some kind and then do the compilation and dumping process server side. This is a bit like how Apple compiled LLVM bitcode itself for delivery. However then the build process needs to be sandboxed and at that point why not go full FaaS and let users upload whatever binaries they like? AWS is doing it successfully.

by paulgb 3y ago

mike_hearn 3y ago

Right, but that trick also isn't new. emacs was doing it decades ago and there are JVMs that also do it. That's how GraalVM native images can start and run faster than C programs do: the app is initialized at build time and then the state is just mmapped into a pre-compiled native process. HotSpot has a less aggressive version of this where you can pre-initialize a lot of VM state and dump it to a file for faster startup time. It's about a 30% win and that's going up over time, but it doesn't AOT compile everything. Of course, if you're serious about instant startup from zero then you end up going the native-image route, but then what value is WASM adding? What's being shipped to the edge in that case is a compiled binary anyway. There is some scope here for threading the needle - for example, an edge worker implementation could be given compiled bytecode of some kind and then do the compilation and dumping process server side. This is a bit like how Apple compiled LLVM bitcode itself for delivery. However then the build process needs to be sandboxed and at that point why not go full FaaS and let users upload whatever binaries they like? AWS is doing it successfully.