4 ms·

The lucet compiler and runtime each assume the other is implemented correctly, and its the job of some external system to make sure the runtime only loads code

The lucet compiler and runtime each assume the other is implemented correctly, and its the job of some external system to make sure the runtime only loads code that came from the compiler. (We have infrastructure at Fastly that already does this for our edge cloud, and every use case will have different requirements). The shared object code, when executed with lucet-runtime, should provide guarantees equivalent to those given by the wasm spec. However, we're not 100% to spec compliance yet, so there are some corners (e.g. import globals) that are not implemented. These dont cause a problem in practice, at the moment, because none of the toolchains we use to emit wasm use those features. Loading code into the runtime is fast because its mostly a call to `dlopen`, followed by deserializing some metadata (with effort made to make this as efficient as possible). Instantiating modules is fast because it amortizes the syscall overhead by having pools of instances mostly-set-up ahead of time.

acqq 8y ago
> Loading code into the runtime is fast because its mostly a call to `dlopen Does that mean that you measure only loading and not the compilation and verification in your “50 ms” time?
- phickey 8y ago
  Instantiation takes under 50 microseconds (us) on the lab machine I tested on, and 65us on my colleague's laptop. Loading the code takes about that long as well (see thread: https://twitter.com/acfoltzer/status/1111387279434485760 https://twitter.com/acfoltzer/status/1111387279434485760). Compilation is not counted towards any of those tallies. In our use case, we do compilation on a control plane system and distribute the shared object file to the fleet, so we aren't too concerned by it. For applications where compilation time is a bigger concern, I'm super impressed by this (still early) work on a one-pass wasm compiler: https://github.com/CraneStation/lightbeam https://github.com/CraneStation/lightbeam
  - acqq 8y ago
    > 50 microseconds Yes, sorry for my error in writing, of course, 50 ms would be only 20 times per second. Thanks a lot for your explanations.
- smjain 8y ago
  so do we keep a pool of VMs with the so file loaded already and instantiate only the module on demand which means allocation of memory and setup of other data structures

acqq 8y ago

> Loading code into the runtime is fast because its mostly a call to `dlopen Does that mean that you measure only loading and not the compilation and verification in your “50 ms” time?

phickey 8y ago
Instantiation takes under 50 microseconds (us) on the lab machine I tested on, and 65us on my colleague's laptop. Loading the code takes about that long as well (see thread: https://twitter.com/acfoltzer/status/1111387279434485760 https://twitter.com/acfoltzer/status/1111387279434485760). Compilation is not counted towards any of those tallies. In our use case, we do compilation on a control plane system and distribute the shared object file to the fleet, so we aren't too concerned by it. For applications where compilation time is a bigger concern, I'm super impressed by this (still early) work on a one-pass wasm compiler: https://github.com/CraneStation/lightbeam https://github.com/CraneStation/lightbeam
- acqq 8y ago
  > 50 microseconds Yes, sorry for my error in writing, of course, 50 ms would be only 20 times per second. Thanks a lot for your explanations.
smjain 8y ago
so do we keep a pool of VMs with the so file loaded already and instantiate only the module on demand which means allocation of memory and setup of other data structures