Closed tomaka closed 4 years ago
@pepyakin Is there a good explanation somewhere of what the difference between the two is?
Not sure if there is, but here is tl;dr:
lucet was started by Fastly for their edge computation thingy (and wasmtime was started by Mozilla). Because of that this engine has some quite specific features.
For one, lucet has a strong inclination towards ahead-of-time execution, so much, that the pipeline is divided on two parts: 1. compile wasm code and get a friggin *.so
and 2. when execution needed they would load this *.so
quickly and execute it. I mean it, looks like it's designed with out-of-process compiler in mind. They in general try to optimize for super fast startup time.
Another feature (in fact it's why lucet surfaced in our discussion in the first place) is that they support stack switching. That would allow lucet to better fit into the execution model of substrate-lite: instead of blocking host functions they could be implemented in async fashion with lucet.
Alas, in the same discussion, we uncovered that it would be a bit of a pain to use lucet because, (after glancing at the public api), it requires declaring all the host functions upfront. And unfortunately, substrate-lite, akin substrate, is structured with a variable host function list, so that would require a bit of refactoring.
To get more info about lucet you can look at their docs
A relevant issue for wasmtime https://github.com/bytecodealliance/wasmtime/issues/1007
I'd go with keeping wasmtime
, and when https://github.com/bytecodealliance/wasmtime/issues/1007 is done we can get rid of the weird task-switching code.
I'm really not a fan of lucet's approach.
For reference, in #55 I went with my own library (https://github.com/tomaka/corooteen) because:
Yielder
by reference only, and not by value, meaning that I can't "inject" this yielder in the callbacks called by wasmtime
.Good job!
I guess this can be closed now
As recommended by @pepyakin
https://docs.rs/lucet-runtime