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

71–80 of 96 posts

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

#71

Post by [deleted] »

pjmlp wrote: post #67
vijaybritto wrote: post #60

Earlier quoted context omitted.

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

[deleted]

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

#72

Post by zaarn »

AnIdiotOnTheNet wrote: post #70
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 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.

For innative it matters what LLVM supports and LLVM supports already dictates the support of many programming languages atleast as a superset (Rust and Go support a subset of what LLVM supports), I don't see how this is "one more layer of abstraction will fix the whole mess" when it reuses existing abstractions.

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

#73

Post by protomyth »

pjmlp wrote: post #68
protomyth wrote: post #21

Earlier quoted context omitted.

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.

Which browser gave the JVM the same access as Javascript because it sure wasn't Netscape.

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

#74

Post by imtringued »

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.

Not it wouldn't be because most bytecodes generally operate at a higher level. A single java call instruction can in theory turn into an unbounded number of machine instructions through inlining. Therefore limiting the machine to only executing entire java instructions will make it extremely slow because it cannot use any optimizations.

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

#75

Post by imtringued »

politician wrote: post #53
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.)

But now you can in theory run your programs on that doesn't suffer from those vulnerabilities thanks to the power of WASM.

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

#76

Post by imtringued »

gravypod wrote: post #25
jchw wrote: post #24

Earlier quoted context omitted.

In fact there’s almost certainly more ways, too. You could probably transpile WASM to JVM bytecode. These things are most useful when you already are in the JVM anyways, I can’t imagine most people writing software in pure Rust would jump for this, especially given that WASM has a lot to offer for this use case already and has good momentum. I see it as a better fit, with useful security guarantees and a simple desig…

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…

>Wasm is a good idea but it's going to need to reimplement a lot of existing code (optimizing + jit).

Where the hell did you get that idea? WASM can be used as just another frontend for javascript JIT engines like V8 or SpiderMonkey.

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

#77

Post by mises »

scriptproof wrote: post #57
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.

Asm for Assembly, so maybe WAsm is correct?

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

#79

Post by liquid153 »

WASM sounds great and all with it’s sandbox like NaCl. But I have to imagine over 90% of client and server computers are x86 and ARM and I don’t see those targets losing any share in the near or long term. Also I don’t see wasm being used in micro controllers as well.

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

#80

Post by pjmlp »

protomyth wrote: post #73
pjmlp wrote: post #68

Earlier quoted context omitted.

Actually it did.

Which browser gave the JVM the same access as Javascript because it sure wasn't Netscape.

All of them, given the right access permissions.

Better read the documentation?

https://docs.oracle.com/javase/tutorial/deployment/applet/ma...

Post reply on HN