11 ms·

Lucet: Native WebAssembly Compiler and Runtime

387 points by kickdaddy 8y ago

phickey 8y ago
Author here- happy to take questions.
- arcatek 8y ago
  What would you say are the current main limitations of this approach? What is Lucet not meant to be good at?
  - phickey 8y ago
    At the moment, a lot of WASM tooling assumes instances interact with a JS engine. So, we aren't compatible with a bunch of existing tooling, like Rust's wasm-bindgen. We're working on our own tool to fill that hole in the ecosystem. We also aren't 100% of the way to spec compliance yet. We have a plan to get there, but spent the last year or so putting the bulk of our effort into performance and integration with our edge cloud systems.
    - vvanders 8y ago
      That's awesome. One of my main complaints with wasm-bindgen is it doesn't let you pull in any C libraries(vs older emscripten path) effectively walling off one of Rusts awesome capabilities(interop with a large established ecosystem). Whatever tool that takes it's place here would be awesome if you plug in cleanly with the CC crate. I've had a lot of success using Rust as the glue between a lot of existing C/C++ libraries and would love to carry that forward to the WASM world.
- kbumsik 8y ago
  I didn't know about WASI before and it looks great. As a C/C++ dev, one of my concerns about WASM was that most of native WASM runtimes are interfacing towards Emscripten which is not quite standardized. Do you expect WASI will soon replace the current Emscripten exports interfaces?
  - phickey 8y ago
    We hope so! Mozilla has been working on WASI support from Rust, and our team is working on supporting it from AssemblyScript as well: https://github.com/jedisct1/wasa https://github.com/jedisct1/wasa.
- acqq 8y ago
  How do you achieve the security guaraties for the content of the .so? Are they equivalent to those of wasm? If yes, how (technicalky) you achieve the reported speedup in verifying the security?
  - phickey 8y ago
    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
- jeltz 8y ago
  Why did you write your own implementation rather than contribute directly to any of the projects with similar aims, e.g. wasmer or wasmtime.
  - mwcampbell 8y ago
    I'm guessing Lucet was developed concurrently with the others, but unlike them, it had an extended period of internal development and testing first.
  - phickey 8y ago
    We started the codebase that became Lucet in July 2017. It went through a few fast iterations, and by Jan 2018 we had Cranelift running with AOT compilation. In the early days of Cranelift that meant adding support for position-independent code output and filling in a bunch of gaps in the x86_64 encodings and other really low level stuff. At the time, wasmtime (under the name wasm-standalone, i think?) was a lot less mature, and wasmer was not public yet. So, in a sense, we did (& continue to) contribute to both of those runtimes via Cranelift and other dependencies like Faerie. We spent the bulk of 2018 solving performance and integration problems, rather than cleaning up the codebase to the point where we could open source it. In the meantime wasmer was released, and both wasmtime and wasmer made a ton of progress. Now that our stuff is open source, it is easier for us to collaborate with other runtimes, possibly by moving more code back into the common Cranelift parent, or by adopting modules from each other.
    - jeltz 8y ago
      Thanks for the answer, that makes a lot of sense.
sansnomme 8y ago
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?
- phickey 8y ago
  I have not compared it to LuaJIT, but given that Lucet uses an AOT architecture, its hard to make a fair comparison. There is no GUI story yet, but Lucet provides a WASI (https://wasi.dev https://wasi.dev) implementation, so as that standard evolves, we may be able to support GUIs through those interfaces.
- MuffinFlavored 8y ago
  What other fast JITs in existence are there that are worth noting?
  - saagarjha 8y ago
    HotSpot, the JavaScript JITs?
azakai 8y ago
> 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.?
- phickey 8y ago
  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#caveats 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.
  - tick_tock_tick 8y ago
    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.
    - Yetanfou 8y ago
      From what I gather the thing is based on WASI which in early beta and for which many parts don't exist or don't work, networking and file access being a few of those [1]: Note that everything here is a prototype, and while a lot of stuff works, there are numerous missing features and some rough edges. One big thing that's not done yet is the actual mechanism to provide a directory as a pre-opened capability, to allow files to be opened. Some of the pieces are there (__wasilibc_register_preopened_fd) but they're not used yet. Networking support is also incomplete. In other words, this is a somewhat premature announcement when it comes to fulfilling those promises. [1] https://github.com/CraneStation/wasmtime/blob/master/docs/WASI-intro.md https://github.com/CraneStation/wasmtime/blob/master/docs/WA...
      - sunfish 8y ago
        That sentence about pre-opened directory capabilities not being supported is actually outdated. They're supported now, so I've now updated the documentation. Thanks for pointing that out!
gaze 8y ago
Why use this as opposed to Google NaCl or PNaCl?
- jedisct1 8y ago
  (P)NaCl is dead: https://www.theregister.co.uk/2017/05/31/googles_portable_native_client_to_be_killed/ https://www.theregister.co.uk/2017/05/31/googles_portable_na...
- pcwalton 8y ago
  The NaCl/PNaCl team is working on Web Assembly these days, for one.
- kbumsik 8y ago
  Google already deprecated them in favor of WebAssembly.
- mshockwave 8y ago
  (P)NaCl is dead a long long time ago
cagenut 8y ago
how does it look like this will work from a stack and a request/response flow perspective? meaning, am I calling it as a function from within my vcl config? or am i mapping my service-id straight to a binary?
- phickey 8y ago
  We're not quite there yet, but we're working on answering those questions right now. Stay tuned!
peter998 8y ago
Interesting! I wonder this compares with other WebAssembly runtimes (Wasmer?)
- syrusakbary 8y ago
  Thanks for asking! I'm Syrus, I started the Wasmer project. 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 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 https://github.com/wasmerio/wasmer
  - phickey 8y ago
    That is a good summary! Lucet's runtime has a C API as well. We haven't created bindings to languages beyond C and Rust, but it should be pretty straightforward using the C API.
    - syrusakbary 8y ago
      Thanks for the correction! And congrats for the great work
steveklabnik 8y ago
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 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.)
- k__ 8y ago
  Sounds really exciting. Are comparisons to things like the JVM or native binaries already possible?
  - steveklabnik 8y ago
    I'm not 100% sure what you mean by that final sentence, could you maybe elaborate?
    - k__ 8y ago
      Sure. Does WASM have better performance than the JVM? If not, could it have better performance theoretically? Is it more secure? How much slower than a regular binary would it be? etc.
      - steveklabnik 8y ago
alexellisuk 8y ago
Excited to see this come about and how it could be used with the OpenFaaS watchdog on Kubernetes. https://docs.openfaas.com/architecture/watchdog/ 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 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
- phickey 8y ago
  You need to checkout submodules - $ git submodule init && git submodule update. Sorry, multiple people have reported this problem, and we're adding it to the docs right now!
  - jedisct1 8y ago
    Indeed. And even if you know that a project uses submodules, forgetting `--recursive` happens constantly. The script will now automatically install the required submodules.
- phickey 8y ago
  to answer the first question: It is 50us create a new instance from a loaded WebAssembly module. The module is compiled AOT into a shared object file, which is then loaded into the runtime using `dlopen`. We create instances from a region, which is basically a pool of memory that is already mostly setup, to minimize the computation & syscalls required in instance creation.
vortico 8y ago
Native WebAssembly sure is an exciting topic. But I can't think of a single concrete use case that someone could use---besides having another standard for secure bytecode to choose from. Help?
- themacguffinman 8y ago
  It could take off for the same reason node.js took off: it's easy and simple to leverage your existing frontend codebase for backend use. Running the same webassembly directly in your backend environment may be easier than compiling to a different target and debugging the quirky differences.
- steveklabnik 8y ago
  As the blog post mentions, > Lucet is designed to take WebAssembly beyond the browser, and build a platform for faster, safer execution on Fastly’s edge cloud. > Lucet is the engine behind Terrarium, our experimental platform for edge computation using WebAssembly. Soon, we will make it available on Fastly’s edge cloud as well. You can see the Terrarium announcement here: https://www.fastly.com/blog/edge-programming-rust-web-assembly https://www.fastly.com/blog/edge-programming-rust-web-assemb... So that's at one concrete use case for you! I'm sure we'll be seeing more pop up in the future, there's so much going on here.
- pier25 8y ago
  For example integrating third party crossplatform code (plugins, mods, behaviors, etc) into native projects (game engines, databases, etc).
StavrosK 8y ago
Now that I see this, a question comes to mind: Why do we have yet another VM? Why didn't browsers just implement LLVM? Is it the sandbox? Don't get me wrong, I'm excited to see wasm spread, but the question does cross my mind.
- zapita 8y ago
  The spiritual ancestor or wasm, pnacl, was in fact based on a safe subset of the llvm IR. I think llvm/wasm interop will be hugely important, and will receive a lot of attention from the nascent wasm ecosystem.
- steveklabnik 8y ago
  LLVM is not really a VM in the sense of the JVM. LLVM-IR is not platform independent, and was never intended for this use-case. It is also significantly more complex than wasm, which is partially why wasm ended up working. Start small, add over time: that's the way of the web platform.
  - StavrosK 8y ago
    I see, that's a very good point. Thank you.
  - Sophistifunk 8y ago
    Every reliable complex system started as a reliable simple system and evolved.
    - jodrellblank 8y ago
      "Worse Is Better", but describing it from the other side.
  - kllrnohj 8y ago
    More importantly LLVM-IR isn't stable. It's intended to just be an intermediate between the bundled front-ends & back-ends. There's some limited compatibility provided ( http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compa... ), but nothing close to suitable for an actually persisted format.
cck68 7y ago
Can you comment on how big an effort it would be to support arm platforms?

387 points by kickdaddy 8y ago

phickey 8y ago

Author here- happy to take questions.

arcatek 8y ago
What would you say are the current main limitations of this approach? What is Lucet not meant to be good at?
- phickey 8y ago
  At the moment, a lot of WASM tooling assumes instances interact with a JS engine. So, we aren't compatible with a bunch of existing tooling, like Rust's wasm-bindgen. We're working on our own tool to fill that hole in the ecosystem. We also aren't 100% of the way to spec compliance yet. We have a plan to get there, but spent the last year or so putting the bulk of our effort into performance and integration with our edge cloud systems.
  - vvanders 8y ago
    That's awesome. One of my main complaints with wasm-bindgen is it doesn't let you pull in any C libraries(vs older emscripten path) effectively walling off one of Rusts awesome capabilities(interop with a large established ecosystem). Whatever tool that takes it's place here would be awesome if you plug in cleanly with the CC crate. I've had a lot of success using Rust as the glue between a lot of existing C/C++ libraries and would love to carry that forward to the WASM world.
kbumsik 8y ago
I didn't know about WASI before and it looks great. As a C/C++ dev, one of my concerns about WASM was that most of native WASM runtimes are interfacing towards Emscripten which is not quite standardized. Do you expect WASI will soon replace the current Emscripten exports interfaces?
- phickey 8y ago
  We hope so! Mozilla has been working on WASI support from Rust, and our team is working on supporting it from AssemblyScript as well: https://github.com/jedisct1/wasa https://github.com/jedisct1/wasa.
acqq 8y ago
How do you achieve the security guaraties for the content of the .so? Are they equivalent to those of wasm? If yes, how (technicalky) you achieve the reported speedup in verifying the security?
- phickey 8y ago
  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
jeltz 8y ago
Why did you write your own implementation rather than contribute directly to any of the projects with similar aims, e.g. wasmer or wasmtime.
- mwcampbell 8y ago
  I'm guessing Lucet was developed concurrently with the others, but unlike them, it had an extended period of internal development and testing first.
- phickey 8y ago
  We started the codebase that became Lucet in July 2017. It went through a few fast iterations, and by Jan 2018 we had Cranelift running with AOT compilation. In the early days of Cranelift that meant adding support for position-independent code output and filling in a bunch of gaps in the x86_64 encodings and other really low level stuff. At the time, wasmtime (under the name wasm-standalone, i think?) was a lot less mature, and wasmer was not public yet. So, in a sense, we did (& continue to) contribute to both of those runtimes via Cranelift and other dependencies like Faerie. We spent the bulk of 2018 solving performance and integration problems, rather than cleaning up the codebase to the point where we could open source it. In the meantime wasmer was released, and both wasmtime and wasmer made a ton of progress. Now that our stuff is open source, it is easier for us to collaborate with other runtimes, possibly by moving more code back into the common Cranelift parent, or by adopting modules from each other.
  - jeltz 8y ago
    Thanks for the answer, that makes a lot of sense.

sansnomme 8y ago

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?

phickey 8y ago
I have not compared it to LuaJIT, but given that Lucet uses an AOT architecture, its hard to make a fair comparison. There is no GUI story yet, but Lucet provides a WASI (https://wasi.dev https://wasi.dev) implementation, so as that standard evolves, we may be able to support GUIs through those interfaces.
MuffinFlavored 8y ago
What other fast JITs in existence are there that are worth noting?
- saagarjha 8y ago
  HotSpot, the JavaScript JITs?

azakai 8y ago

> 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.?

phickey 8y ago
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#caveats 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.
- tick_tock_tick 8y ago
  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.
  - Yetanfou 8y ago
    From what I gather the thing is based on WASI which in early beta and for which many parts don't exist or don't work, networking and file access being a few of those [1]: Note that everything here is a prototype, and while a lot of stuff works, there are numerous missing features and some rough edges. One big thing that's not done yet is the actual mechanism to provide a directory as a pre-opened capability, to allow files to be opened. Some of the pieces are there (__wasilibc_register_preopened_fd) but they're not used yet. Networking support is also incomplete. In other words, this is a somewhat premature announcement when it comes to fulfilling those promises. [1] https://github.com/CraneStation/wasmtime/blob/master/docs/WASI-intro.md https://github.com/CraneStation/wasmtime/blob/master/docs/WA...
    - sunfish 8y ago
      That sentence about pre-opened directory capabilities not being supported is actually outdated. They're supported now, so I've now updated the documentation. Thanks for pointing that out!

gaze 8y ago

Why use this as opposed to Google NaCl or PNaCl?

jedisct1 8y ago
(P)NaCl is dead: https://www.theregister.co.uk/2017/05/31/googles_portable_native_client_to_be_killed/ https://www.theregister.co.uk/2017/05/31/googles_portable_na...
pcwalton 8y ago
The NaCl/PNaCl team is working on Web Assembly these days, for one.
kbumsik 8y ago
Google already deprecated them in favor of WebAssembly.
mshockwave 8y ago
(P)NaCl is dead a long long time ago

cagenut 8y ago

how does it look like this will work from a stack and a request/response flow perspective? meaning, am I calling it as a function from within my vcl config? or am i mapping my service-id straight to a binary?

phickey 8y ago
We're not quite there yet, but we're working on answering those questions right now. Stay tuned!

peter998 8y ago

Interesting! I wonder this compares with other WebAssembly runtimes (Wasmer?)

syrusakbary 8y ago
Thanks for asking! I'm Syrus, I started the Wasmer project. 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 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 https://github.com/wasmerio/wasmer
- phickey 8y ago
  That is a good summary! Lucet's runtime has a C API as well. We haven't created bindings to languages beyond C and Rust, but it should be pretty straightforward using the C API.
  - syrusakbary 8y ago
    Thanks for the correction! And congrats for the great work

steveklabnik 8y ago

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 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.)

k__ 8y ago
Sounds really exciting. Are comparisons to things like the JVM or native binaries already possible?
- steveklabnik 8y ago
  I'm not 100% sure what you mean by that final sentence, could you maybe elaborate?
  - k__ 8y ago
    Sure. Does WASM have better performance than the JVM? If not, could it have better performance theoretically? Is it more secure? How much slower than a regular binary would it be? etc.
    - steveklabnik 8y ago

alexellisuk 8y ago

Excited to see this come about and how it could be used with the OpenFaaS watchdog on Kubernetes. https://docs.openfaas.com/architecture/watchdog/ 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 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

phickey 8y ago
You need to checkout submodules - $ git submodule init && git submodule update. Sorry, multiple people have reported this problem, and we're adding it to the docs right now!
- jedisct1 8y ago
  Indeed. And even if you know that a project uses submodules, forgetting `--recursive` happens constantly. The script will now automatically install the required submodules.
phickey 8y ago
to answer the first question: It is 50us create a new instance from a loaded WebAssembly module. The module is compiled AOT into a shared object file, which is then loaded into the runtime using `dlopen`. We create instances from a region, which is basically a pool of memory that is already mostly setup, to minimize the computation & syscalls required in instance creation.

vortico 8y ago

Native WebAssembly sure is an exciting topic. But I can't think of a single concrete use case that someone could use---besides having another standard for secure bytecode to choose from. Help?

themacguffinman 8y ago
It could take off for the same reason node.js took off: it's easy and simple to leverage your existing frontend codebase for backend use. Running the same webassembly directly in your backend environment may be easier than compiling to a different target and debugging the quirky differences.
steveklabnik 8y ago
As the blog post mentions, > Lucet is designed to take WebAssembly beyond the browser, and build a platform for faster, safer execution on Fastly’s edge cloud. > Lucet is the engine behind Terrarium, our experimental platform for edge computation using WebAssembly. Soon, we will make it available on Fastly’s edge cloud as well. You can see the Terrarium announcement here: https://www.fastly.com/blog/edge-programming-rust-web-assembly https://www.fastly.com/blog/edge-programming-rust-web-assemb... So that's at one concrete use case for you! I'm sure we'll be seeing more pop up in the future, there's so much going on here.
pier25 8y ago
For example integrating third party crossplatform code (plugins, mods, behaviors, etc) into native projects (game engines, databases, etc).

StavrosK 8y ago

Now that I see this, a question comes to mind: Why do we have yet another VM? Why didn't browsers just implement LLVM? Is it the sandbox? Don't get me wrong, I'm excited to see wasm spread, but the question does cross my mind.

zapita 8y ago
The spiritual ancestor or wasm, pnacl, was in fact based on a safe subset of the llvm IR. I think llvm/wasm interop will be hugely important, and will receive a lot of attention from the nascent wasm ecosystem.
steveklabnik 8y ago
LLVM is not really a VM in the sense of the JVM. LLVM-IR is not platform independent, and was never intended for this use-case. It is also significantly more complex than wasm, which is partially why wasm ended up working. Start small, add over time: that's the way of the web platform.
- StavrosK 8y ago
  I see, that's a very good point. Thank you.
- Sophistifunk 8y ago
  Every reliable complex system started as a reliable simple system and evolved.
  - jodrellblank 8y ago
    "Worse Is Better", but describing it from the other side.
- kllrnohj 8y ago
  More importantly LLVM-IR isn't stable. It's intended to just be an intermediate between the bundled front-ends & back-ends. There's some limited compatibility provided ( http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compa... ), but nothing close to suitable for an actually persisted format.

cck68 7y ago

Can you comment on how big an effort it would be to support arm platforms?