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

51–60 of 96 posts

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

#51

Post by soup10 »

jchw wrote: post #31
gravypod wrote: post #25

Earlier quoted context omitted.

The benefits of the JVM still stand out to me personally. Run anywhere, generate machine code at run time most place, world class optimizing compiler, battle tested & ready to deploy, integration with existing code base for gradual rewrites, etc. Wasm is a good idea but it's going to need to reimplement a lot of existing code (optimizing + jit). Doable and maybe it will convince people to do what has been a great ide…

The JVM had many chances to realize that goal. Java applets, J2ME, etc. I’m not sure which particular issue really kept it from keeping mindshare. I don’t think the virtual machine itself was ever really the problem. Still, since the Java platform didn’t capture this use case of a general purpose abstract machine, it makes a whole lot of sense to develop something like WASM. It’s a much more neutral platform to build…

java browser plugins have always been poorly designed and implemented

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

#52

Post by weego »

techntoke wrote: post #19
kbumsik wrote: post #11

Earlier quoted context omitted.

> WASM is already bad for user security Any source?

You are running a binary and you have to trust the sandbox. Hasn't worked so well for web browsers even with JavaScript.

Also didn't work well for Flash.

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

#53

Post by politician »

microcolonel wrote: post #46

Alternatively: run native code at least 5% slower than before.

Before or after turning off Hyper Threading and speculative execution on your Intel microprocessor?

(The point being that 5% slowdown is a drop in the bucket compared to what we've already lost due to Intel's chip design problems. AIUI, HT is a 15-20% slowdown, and SE was another 20% slowdown.)

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

#54

Post by hackerpacker »

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?

" It's not a language"

It sure looks like a language to me, like some sort of assembly language.

https://webassembly.org/getting-started/advanced-tools/

https://developer.mozilla.org/en-US/docs/WebAssembly/Text_fo...

granted this is a textual representation (very useful in certain circumstances) but that is semantics. Having done plenty of assembly, I don't see a huge distinction here.

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

#55

Post by writepub »

saagarjha wrote: post #40
lightgreen wrote: post #39

Earlier quoted context omitted.

“Statically validated” AFAIU means there are no runtime checks. E. g. WASM stack local variables and globals are statically validated. Compiler can translate loads and stores to locals and globals to simple movs. There are no additional runtime checks, no overhead. Unlike linear memory.

As far as I could parse that comment, it's saying that function calls are statically validated and that memory is linear. Not that all memory accesses can be statically validated.

Given WASM's 32 bit address space, you can effectively validate a programs memory access statically, with a one time initialization in virtual memory - for instance if you'd like to restrict all WASM memory to 64MB, you can allocate/map it to the top of a 4GB virtual address space, effectively giving it a start address of 4GB-64MB.

Since OS/process virtual memory bound checking is handled by the hardware, the one time setup above will lock down WASM memory access to within the 64MB, without software runtime overheads.

This is exactly why WASM memory was picked to be linear (unlike virtual memory that can have holes in continuity)

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

#56

Post by aclatuts »

forty wrote: post #50
feniv wrote: post #26

WebAssembly on desktop and servers is maturing pretty rapidly! There are several backend interpreters already in Rust and Go (life). The native, compiled options are even faster, Fastly's Lucet compiler and runtime was one of the first to implement WASI ( https://wasi.dev/ ): https://www.fastly.com/blog/announcing-lucet-fastly-native-w... The differentiator for InNative seems to be the ability to bypass the sandbox a…

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

It is nice in development to have bcrypt, openssl, etc for other languages without a build step and build tools

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

#57

Post by scriptproof »

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.

You can avoid the effort to use the uppercase key and write wasm (or Wasm), that is the correct typography. Asm in wasm is acronym for nothing.

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

#58

Post by vijaybritto »

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.

If your native code runs on different platforms, you can compile it once to wasm and it will run in the same speed on all of those platforms.

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

#59

Post by zaarn »

forty wrote: post #50
feniv wrote: post #26

WebAssembly on desktop and servers is maturing pretty rapidly! There are several backend interpreters already in Rust and Go (life). The native, compiled options are even faster, Fastly's Lucet compiler and runtime was one of the first to implement WASI ( https://wasi.dev/ ): https://www.fastly.com/blog/announcing-lucet-fastly-native-w... The differentiator for InNative seems to be the ability to bypass the sandbox a…

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 problem that can be fixed by using WASM as intermediate and porting a WASM Runtime to that architecture.

Something like Innative would also enable desktop applications to be independent of the OS and architecture. The same binary would run on x86_64 Windows, PowerPC Mac and ARMv8 Linux.

It's basically Java but you don't have to use Java to get all the good parts.

(Disclaimer: I know the main dev of innative and do some WASM work myself)

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

#60

Post by vijaybritto »

forty wrote: post #50
feniv wrote: post #26

WebAssembly on desktop and servers is maturing pretty rapidly! There are several backend interpreters already in Rust and Go (life). The native, compiled options are even faster, Fastly's Lucet compiler and runtime was one of the first to implement WASI ( https://wasi.dev/ ): https://www.fastly.com/blog/announcing-lucet-fastly-native-w... The differentiator for InNative seems to be the ability to bypass the sandbox a…

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 happened before the WebAssembly compilation step."

Post reply on HN