Live data from Hacker News

Lucet: Native WebAssembly Compiler and Runtime

fastly.com

31–40 of 99 posts

Re: Lucet: Native WebAssembly Compiler and Runtime

#31
post #25

Earlier quoted context omitted.

Sounds really exciting. Are comparisons to things like the JVM or native binaries already possible?

I'm not 100% sure what you mean by that final sentence, could you maybe elaborate?

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.

Re: Lucet: Native WebAssembly Compiler and Runtime

#32

Earlier quoted context omitted.

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.

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…

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!

Re: Lucet: Native WebAssembly Compiler and Runtime

#33
post #31

Earlier quoted context omitted.

I'm not 100% sure what you mean by that final sentence, could you maybe elaborate?

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.

Ah, cool.

Performance is really difficult to properly measure, because each of these projects have different performance profiles, and new ones keep popping up, like Lucet did today! And if you write a benchmark, then something like https://hacks.mozilla.org/2018/10/calls-between-javascript-a... happens, and all of a sudden the numbers are all different. So it's really hard to speak about wasm generally this way, it's better to talk about specific implementations and use-cases, IMHO. And to understand that benchmarks need to be updated in order to still be relevant.

Security is an interesting axis; like the JVM (as far as I know), wasm is memory safe by design. But security is more holistic than that. One interesting thing about wasm is that you have to say up-front what things you want to call in the host, which provides the ability for the host to say "nope, you're not gonna be able to do that." And of course, logic bugs can lead to security vulnerabilities in all of these platforms.

Re: Lucet: Native WebAssembly Compiler and Runtime

#34

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…

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.

Re: Lucet: Native WebAssembly Compiler and Runtime

#35
post #31

Earlier quoted context omitted.

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.

Ah, cool. Performance is really difficult to properly measure, because each of these projects have different performance profiles, and new ones keep popping up, like Lucet did today! And if you write a benchmark, then something like https://hacks.mozilla.org/2018/10/calls-between-javascript-a... happens, and all of a sudden the numbers are all different. So it's really hard to speak about wasm generally this way, it'…

I see.

Nice, sounds like the Android/Fuchsia approach security-wise :)

Re: Lucet: Native WebAssembly Compiler and Runtime

#36

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

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,…

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.

Re: Lucet: Native WebAssembly Compiler and Runtime

#37
post #31

Earlier quoted context omitted.

I'm not 100% sure what you mean by that final sentence, could you maybe elaborate?

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.

Like Steve says, performance is a complicated thing to measure. For one view on it, Lucet ships with a suite of microbenchmarks that compare its execution of wasm with the same C code compiled natively. The `make bench` target runs these. The most alarming regressions are in simple functions that take string arguments - the arguments have to be copied into the sandbox, and then the results copied out, in order to run a very simple function.

So, in those cases, we don't expect to match native, but things will get better when GC proposal lands in WASM, which gives support for operating on memory regions that are outside of WASM linear memory. But in most applications we've experimented with, we haven't found this overhead to be a showstopper.

Re: Lucet: Native WebAssembly Compiler and Runtime

#38
post #31

Earlier quoted context omitted.

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.

Ah, cool. Performance is really difficult to properly measure, because each of these projects have different performance profiles, and new ones keep popping up, like Lucet did today! And if you write a benchmark, then something like https://hacks.mozilla.org/2018/10/calls-between-javascript-a... happens, and all of a sudden the numbers are all different. So it's really hard to speak about wasm generally this way, it'…

I think wasm's memory safety is weaker than JVM. wasm's checking occurs at control flow points and the linear memory boundary, but does not extend down to individual objects. For example arrays are not bound checked in wasm.

Re: Lucet: Native WebAssembly Compiler and Runtime

#39

Earlier quoted context omitted.

Ah, cool. Performance is really difficult to properly measure, because each of these projects have different performance profiles, and new ones keep popping up, like Lucet did today! And if you write a benchmark, then something like https://hacks.mozilla.org/2018/10/calls-between-javascript-a... happens, and all of a sudden the numbers are all different. So it's really hard to speak about wasm generally this way, it'…

I think wasm's memory safety is weaker than JVM. wasm's checking occurs at control flow points and the linear memory boundary, but does not extend down to individual objects. For example arrays are not bound checked in wasm.

Wasm doesn't really have "arrays", so I don't think wasm checking them would really make sense. I guess you could argue that this is a distinction without a difference. You still won't get memory unsafety, which in my mind, is the higher order bit. YMMV of course.

Re: Lucet: Native WebAssembly Compiler and Runtime

#40
post #30

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…

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!

Indeed.

And even if you know that a project uses submodules, forgetting `--recursive` happens constantly.

The script will now automatically install the required submodules.

Post reply on HN