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

InNative: Run WebAssembly Outside the Sandbox at 95% Native Speed

innative.dev

Post reply on HN
Print view View original

61–70 of 96 posts

Re: InNative: Run WebAssembly Outside the Sandbox at 95% Native Speed

#61

Post by WAHa_06x36 »

mises wrote: post #4
ryacko wrote: post #2

"We could break the stranglehold of i386 on the software industry and free developers to experiment with novel CPU architectures without having to worry about whether our favorite language compiles to it." WASM is equivalent to early 80s ISAs but with different opcodes. Native WASM would be most efficient.

Literally the whole point of WASM is fast, sandboxed code. It's not a language, it's an LLVM target. So why turn LLVM IR into a native binary? It's basically the same thing as "native wasm", whatever that would mean. "Native wasm" is just JITed bytecode. Either that, or you're turning it into a normal binary, in which case, why even use WASM?

LLVM IR is not architecture-independent. It encodes architecture and ABI assumptions, and is not portable.

Also, this is not "JITed bytecode", it is compiled AOT.

Re: InNative: Run WebAssembly Outside the Sandbox at 95% Native Speed

#64

Post by fanf2 »

zaarn wrote: post #59
forty wrote: post #50

Earlier quoted context omitted.

I'm wondering what's the point of compiling server side stuff in wasm? Unless I forgot something, all main server languages are rather portable already, either because they are interpreted (python, node, jvm...) or can be compiled to many targets (rust, go...).

You're not confined by the instruction set below. It no longer matters if your language supports PowerPC, Power8, x86, x86_64, ARMv5 through v8 or even more exotics. Similar to the Java VM, which definitely showed the advantage of being more easily portable, it decouples the binary you deploy from the actual hardware. Rust and Go have support for many targets but not as many as other compilers (GCC), a coverage probl…

It’s yet another UNCOL (1958) or ANDF (1987) :-)

https://en.wikipedia.org/wiki/UNCOL https://en.wikipedia.org/wiki/Architecture_Neutral_Distribut...

Re: InNative: Run WebAssembly Outside the Sandbox at 95% Native Speed

#65

Post by zaarn »

fanf2 wrote: post #64
zaarn wrote: post #59

Earlier quoted context omitted.

You're not confined by the instruction set below. It no longer matters if your language supports PowerPC, Power8, x86, x86_64, ARMv5 through v8 or even more exotics. Similar to the Java VM, which definitely showed the advantage of being more easily portable, it decouples the binary you deploy from the actual hardware. Rust and Go have support for many targets but not as many as other compilers (GCC), a coverage probl…

It’s yet another UNCOL (1958) or ANDF (1987) :-) https://en.wikipedia.org/wiki/UNCOL https://en.wikipedia.org/wiki/Architecture_Neutral_Distribut...

Doubtful considering how much work is being done around WASM.

Re: InNative: Run WebAssembly Outside the Sandbox at 95% Native Speed

#66

Post by vnorilo »

writepub wrote: post #17
mises wrote: post #3

"Run a fast, sandboxed bytecode outside of the sandbox by compiling it into a binary" so just a binary. I'm not sure I understand why you would use wasm here. No one writes wasm; you compile to it (usually from llvm ir). Why couldn't you just go straight from llvm ir to a binary; skip the wasm? I suspect I'm missing something here, but it doesn't seem to make sense.

Because LLVM IR is CPU-Arch specific. For instance, IR for x86 cannot be used on ARM CPUs, which is also the reason why Apple's bitcode representation intended to make apps portable, doesn't cross the iOS (ARM) MacOs (x64) boundary, unless ARM ISA emulation is happening in Mac (like in Marzipan?)

It is not so much that the IR is specific, apart from platform intrinsics. It is that almost any optimization pass will encode architectural details, like packing and alignment.

Re: InNative: Run WebAssembly Outside the Sandbox at 95% Native Speed

#67

Post by pjmlp »

vijaybritto wrote: post #60
forty wrote: post #50

Earlier quoted context omitted.

I'm wondering what's the point of compiling server side stuff in wasm? Unless I forgot something, all main server languages are rather portable already, either because they are interpreted (python, node, jvm...) or can be compiled to many targets (rust, go...).

You don't have to recompile for different architectures. Just compile once to wasm and it will run in all platforms it supports at the same speed. Note: the author mentions this too. "WebAssembly’s 32-bit integer indexes break LLVM’s vectorization due to pointer aliasing. Once fixed-width SIMD instructions are added, native WebAssembly will close the gap entirely, because this vectorization analysis will have happene…

UNCOL, ANDF, P-Code, M-Code, JVM, PNaCL, MSIL, TIMI, ...

Re: InNative: Run WebAssembly Outside the Sandbox at 95% Native Speed

#68

Post by pjmlp »

protomyth wrote: post #21
snek wrote: post #16

Earlier quoted context omitted.

We already tried JVM in browsers, remember java applets? I sure remember the security and compatibility problems :) WASM has been designed from the ground up with portability, security, and stability in mind. It is also a lower target than JVM bytecode, which makes it more suitable to represent languages like rust and go. It has also been designed to take advantage of the sandboxed JIT engines that browsers already h…

We already tried JVM in browsers, remember java applets? I sure remember the security and compatibility problems :) Actually, we didn't really try JVM in the browser. We tried it as a plug-in like Flash. The JVM didn't have access to the DOM like Javascript and WASM will have.

Actually it did.

Re: InNative: Run WebAssembly Outside the Sandbox at 95% Native Speed

#69

Post by TheAceOfHearts »

AshleysBrain wrote: post #62

Isn't the sandbox a useful feature of WebAssembly? It gives you much better security guarantees than running untrusted native code on your system.

It looks like they provide different levels of sandboxing, so you can tweak things based on your specific requirements.

Re: InNative: Run WebAssembly Outside the Sandbox at 95% Native Speed

#70

Post by AnIdiotOnTheNet »

zaarn wrote: post #59
forty wrote: post #50

Earlier quoted context omitted.

I'm wondering what's the point of compiling server side stuff in wasm? Unless I forgot something, all main server languages are rather portable already, either because they are interpreted (python, node, jvm...) or can be compiled to many targets (rust, go...).

You're not confined by the instruction set below. It no longer matters if your language supports PowerPC, Power8, x86, x86_64, ARMv5 through v8 or even more exotics. Similar to the Java VM, which definitely showed the advantage of being more easily portable, it decouples the binary you deploy from the actual hardware. Rust and Go have support for many targets but not as many as other compilers (GCC), a coverage probl…

> It no longer matters if your language supports PowerPC, Power8, x86, x86_64, ARMv5 through v8 or even more exotics

Yeah, instead it matters which WASM runtimes it supports and which archs those runtimes support.

But that's ok, we just need one more layer of abstraction to fix the whole mess.

Post reply on HN