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

91–99 of 99 posts

Re: Lucet: Native WebAssembly Compiler and Runtime

#91

Post by Rusky »

pjmlp wrote: post #90
Rusky wrote: post #89

Earlier quoted context omitted.

Using such a VM requires rewriting existing C code. Wasm's approach allows that to happen incrementally, where it matters, by using memory safe languages like Rust, instead of relying on the VM.

Not at all, as proven by memory tagging on Solaris/SPARC, iOS and upcoming Android/ARM v8.3. So leaving memory tagging out of WASM was a deliberate design decision. There are already better alternatives to write secure code if using C is not a requirement, so again nothing new on WASM other than its hype.

Sure, and we use software memory tagging with things like LLVM sanitizers. It's great.

But a) the hardware Wasm needs to support doesn't have tagging, and b) the software equivalent requires support from the allocator and has a large performance penalty.

So yes, it was a deliberate design decision, taken in order to support existing C programs on the Web.

This is really getting tiring- learning from the past is great, but fetishizing it to the point of denying anything new has any value is... not.

Re: Lucet: Native WebAssembly Compiler and Runtime

#92

Post by imtringued »

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.

Where were you when WebGL, WebRTC, HTML5, etc was introduced? Did you ask "Why do we have yet another graphics api/real time communications api/video streaming api?" back then? No you didn't. The web needs solutions that are built for the web, otherwise it's not going to work.

Especially the "Why not the JVM?" questions tick me off. The people asking this question must be living under a rock. The Web already tried java applets and failed.

Re: Lucet: Native WebAssembly Compiler and Runtime

#93

Post by imtringued »

EamonnMR wrote: post #59
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.

I suspect that the JVM isn't an option since Oracle v Google showed that it's not as open as we'd hoped and nobody wants to try the same trick with .NET.

The JVM isn't an option because java applets have failed. They are a massive security nightmare and they only run java, as opposed to everything (at least that's the promise of WASM).

Re: Lucet: Native WebAssembly Compiler and Runtime

#94

Post by acqq »

phickey wrote: post #88
acqq wrote: post #87

Earlier quoted context omitted.

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

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

> 50 microseconds

Yes, sorry for my error in writing, of course, 50 ms would be only 20 times per second. Thanks a lot for your explanations.

Re: Lucet: Native WebAssembly Compiler and Runtime

#95

Post by jeltz »

phickey wrote: post #85
jeltz wrote: post #77

Earlier quoted context omitted.

Why did you write your own implementation rather than contribute directly to any of the projects with similar aims, e.g. wasmer or wasmtime.

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…

Thanks for the answer, that makes a lot of sense.

Re: Lucet: Native WebAssembly Compiler and Runtime

#96

Post by pjmlp »

Rusky wrote: post #91
pjmlp wrote: post #90

Earlier quoted context omitted.

Not at all, as proven by memory tagging on Solaris/SPARC, iOS and upcoming Android/ARM v8.3. So leaving memory tagging out of WASM was a deliberate design decision. There are already better alternatives to write secure code if using C is not a requirement, so again nothing new on WASM other than its hype.

Sure, and we use software memory tagging with things like LLVM sanitizers. It's great. But a) the hardware Wasm needs to support doesn't have tagging, and b) the software equivalent requires support from the allocator and has a large performance penalty. So yes, it was a deliberate design decision, taken in order to support existing C programs on the Web. This is really getting tiring- learning from the past is great…

WASM wouldn't even be a thing if it wasn't for Mozilla politics against PNaCL.

Tiring is the continuous advertising that WASM is the second coming of Christ in VM implementations.

Re: Lucet: Native WebAssembly Compiler and Runtime

#97

Post by Rusky »

pjmlp wrote: post #96
Rusky wrote: post #91

Earlier quoted context omitted.

Sure, and we use software memory tagging with things like LLVM sanitizers. It's great. But a) the hardware Wasm needs to support doesn't have tagging, and b) the software equivalent requires support from the allocator and has a large performance penalty. So yes, it was a deliberate design decision, taken in order to support existing C programs on the Web. This is really getting tiring- learning from the past is great…

WASM wouldn't even be a thing if it wasn't for Mozilla politics against PNaCL. Tiring is the continuous advertising that WASM is the second coming of Christ in VM implementations.

Those "politics" were there for a reason. Wasm is a solid improvement over PNaCl, which I will note you have curiously left out of all your other old-VM-worship claims.

Re: Lucet: Native WebAssembly Compiler and Runtime

#98

Post by smjain »

acqq wrote: post #87
phickey wrote: post #86

Earlier quoted context omitted.

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

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

so do we keep a pool of VMs with the so file loaded already and instantiate only the module on demand which means allocation of memory and setup of other data structures
Post reply on HN