21–30 of 99 posts
How does Lucet's WebAssembly performance compare to LuaJIT (one of the fastest JITs in existence) right now including VM warm-up time? Also, what's the GUI story like outside of browsers?
Really pumped to see this open sourced. And the performance properties look awesome.
One interesting thing we’re seeing in this space is sort of two parallel paths emerge: do you want to support JavaScript, or not? An example of the former is CloudFlare and their Workers platform. Hopefully they’ll follow Fastly’s lead and open source their runtime too, but it’s built on top of V8 because they want to support JavaScript. You also gain the additional advantage of all the engineering that Google puts into V8.
The other option is stuff like Lucent, wasmer, and wasmtime. By dropping the JavaScript requirement, you can build something that really screams, as seen here. You can partially regain some support via AssemblyScript, the TypeScript subset that compiles to JS. But we haven’t seen JavaScript compile directly to wasm yet because if you want that, well, V8 exists. And you do have to build it all yourself.
JavaScript is one of most popular programming programming languages that exists. Time will tell which approach is better, but it’s really fun to watch all of this cool technology explode onto the scene right now.
(Disclaimer: I have connections to all of these projects in various ways. Everyone involved in all of them is doing great work.)
How does Lucet's WebAssembly performance compare to LuaJIT (one of the fastest JITs in existence) right now including VM warm-up time? Also, what's the GUI story like outside of browsers?
What other fast JITs in existence are there that are worth noting?
Interesting! I wonder this compares with other WebAssembly runtimes (Wasmer?)
Lucet just released, but so far these are the current differences as far as I can tell:
1. Wasmer is meant to execute any WebAssembly file and run on any platform. Wasmer currently runs on Mac, Linux and Windows. Lucet only works on Linux at the moment, since its main goal is to be executed on Fastly's infra.
2. We support multiple compiler backends: dynasm, cranelift and LLVM. Each with a tradeoff between runtime speed and compilation speed (more info here https://github.com/wasmerio/wasmer/tree/master/lib#backends ). Lucet's architecture only supports one backend at the moment.
3. Wasmer has multiple interfaces/ABI integrations, including Emscripten, and soon WASI. Lucet initially shipped with WASI support, which is awesome.
4. Wasmer has a C/C++ API and its runtime can be integrated with other languages (C/C++, Rust and PHP at the moment)
And, of course... a link to the project if anyone else wants to take a look! https://github.com/wasmerio/wasmer
The wasm runtime wars are heating up! Exciting times :) Really pumped to see this open sourced. And the performance properties look awesome. One interesting thing we’re seeing in this space is sort of two parallel paths emerge: do you want to support JavaScript, or not? An example of the former is CloudFlare and their Workers platform. Hopefully they’ll follow Fastly’s lead and open source their runtime too, but it’s…
Are comparisons to things like the JVM or native binaries already possible?
> With Lucet, Fastly’s edge cloud can execute tens of thousands of WebAssembly programs simultaneously, in the same process , without compromising security. [emphasis mine] How does it handle Spectre, etc.?
We have a security document that addresses the big picture, and this specific concern as well: https://github.com/fastly/lucet/blob/master/SECURITY.md#cave... For speculative execution, we don't yet implement all of the mitigations possible in Lucet, but will in the near future.
I got an error with the example however.. is everyone else seeing the same thing?
Unpacking wasi-sdk (3.0) ... Setting up wasi-sdk (3.0) ... Removing intermediate container d552f4538e26 ---> 713ff6032205 Step 8/8 : ENV WASI_SDK=/opt/wasi-sdk ---> Running in 4189f307a30e Removing intermediate container 4189f307a30e ---> a142a5620a28 Successfully built a142a5620a28 Successfully tagged lucet-dev:latest Lucet hasn't been installed yet... installing... Creating a RELEASE build cargo build --all --release --bins --lib error: failed to read `/lucet/pwasm-validation/Cargo.toml`
Caused by: No such file or directory (os error 2) Makefile:11: recipe for target 'build' failed make: * [build] Error 101
The wasm runtime wars are heating up! Exciting times :) Really pumped to see this open sourced. And the performance properties look awesome. One interesting thing we’re seeing in this space is sort of two parallel paths emerge: do you want to support JavaScript, or not? An example of the former is CloudFlare and their Workers platform. Hopefully they’ll follow Fastly’s lead and open source their runtime too, but it’s…
Sounds really exciting. Are comparisons to things like the JVM or native binaries already possible?
Earlier quoted context omitted.
We have a security document that addresses the big picture, and this specific concern as well: https://github.com/fastly/lucet/blob/master/SECURITY.md#cave... For speculative execution, we don't yet implement all of the mitigations possible in Lucet, but will in the near future.
So currently it does compromise on security? Seems extremely misleading to claim any security if you are just currently ignoring the last years worth of major security issues.
I'm not sure how you're supposed to handle that, either, given host environment usually does limiting at a process granularity but this doesn't use multiple processes.
Excited to see this come about and how it could be used with the OpenFaaS watchdog on Kubernetes. https://docs.openfaas.com/architecture/watchdog/ - is the 5 nano seconds the time to fork at the OS level or a kind of in-process hot performance? I got an error with the example however.. is everyone else seeing the same thing? Unpacking wasi-sdk (3.0) ... Setting up wasi-sdk (3.0) ... Removing intermediate container d5…