Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lucet: Native WebAssembly Compiler and Runtime

fastly.com

Post reply on HN
Print view View original

41–50 of 99 posts

Re: Lucet: Native WebAssembly Compiler and Runtime

#41

Post by kodablah »

k__ wrote: post #31
steveklabnik wrote: post #28

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.

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

Hard to answer as they're different domains. In theory, once optimized and JIT'd, the asm could be the same on non-GC'd sections. JVM bytecode is higher level which means it both benefits (i.e. can optimize more) and is hamstrung (i.e. GC). As for a "regular binary", the JVM knows no such thing and really neither does WASM. Also depends on what "regular" is (i.e. what does the code do) and which runtimes you use and how much is AOT'd vs JIT'd vs interpreted.

Re: Lucet: Native WebAssembly Compiler and Runtime

#42

Post by vvanders »

phickey wrote: post #6
arcatek wrote: post #3

Earlier quoted context omitted.

What would you say are the current main limitations of this approach? What is Lucet not meant to be good at?

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…

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.

Re: Lucet: Native WebAssembly Compiler and Runtime

#44

Post by themacguffinman »

vortico wrote: post #43

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?

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.

Re: Lucet: Native WebAssembly Compiler and Runtime

#45

Post by steveklabnik »

vortico wrote: post #43

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?

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

Re: Lucet: Native WebAssembly Compiler and Runtime

#46

Post by pjmlp »

steveklabnik wrote: post #39
ridiculous_fish wrote: post #38

Earlier quoted context omitted.

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.

It is possible to corrupt data on the stack due to out of bounds.

Re: Lucet: Native WebAssembly Compiler and Runtime

#47

Post by steveklabnik »

pjmlp wrote: post #46
steveklabnik wrote: post #39

Earlier quoted context omitted.

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.

It is possible to corrupt data on the stack due to out of bounds.

Yes, bugs can always exist.

Re: Lucet: Native WebAssembly Compiler and Runtime

#49

Post by Rusky »

ridiculous_fish wrote: post #38
steveklabnik wrote: post #33

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.

The JVM and wasm have completely different memory safety stories on the inside of the sandbox, because wasm can run arbitrary C, so it has to cope with that somehow.

But the thing Steve is pointing out is that they're equivalent from the outside, where neither can corrupt the host environment.

Re: Lucet: Native WebAssembly Compiler and Runtime

#50

Post by zapita »

StavrosK wrote: post #48

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.

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.
Post reply on HN