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

81–90 of 96 posts

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

#81

Post by gravypod »

imtringued wrote: post #76
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…

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

If JavaScript JITs are anything like Java JITs then it might be that most of the performance-improving optimizations are based on optimizations of how Java/JavaScript operate and recognizing specific patterns that can be replaced with simpler instructions to improve performance. The JavaScript JITs help with the machine code generation but not necessarily with other higher-level optimizations.

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

#82

Post by politician »

imtringued wrote: post #75
politician wrote: post #53

Earlier quoted context omitted.

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.

> on

Did the Mill CPU finally get first silicon? ;)

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

#83

Post by protomyth »

pjmlp wrote: post #80
protomyth wrote: post #73

Earlier quoted context omitted.

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

given the right access permissions.

So, none of them out-of-the-box like Javascript. Given, it didn't really work as far out as 2005[1] which is 10 years after Javascript was introduced, I stand by my original statement.

1) https://www.eclipsezone.com/eclipse/forums/t16762.html

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

#84

Post by pjmlp »

protomyth wrote: post #83
pjmlp wrote: post #80

Earlier quoted context omitted.

All of them, given the right access permissions. Better read the documentation? https://docs.oracle.com/javase/tutorial/deployment/applet/ma...

given the right access permissions. So, none of them out-of-the-box like Javascript. Given, it didn't really work as far out as 2005[1] which is 10 years after Javascript was introduced, I stand by my original statement. 1) https://www.eclipsezone.com/eclipse/forums/t16762.html

Which was a good thing, no one likes cryptominers on their pages, other than hackers that is.

With WASM it will even get better, Flash that one cannot disable.

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

#85

Post by her_tummy_hurts »

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.

WASM is based off of a specification, so compilers target the spec instead of an individual runtime.

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

#86

Post by pjmlp »

zaarn wrote: post #65
fanf2 wrote: post #64

Earlier quoted context omitted.

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.

Usually being hyped by people that apparently don't know the history of bytecode formats since the early 60's.

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

#87

Post by pjmlp »

WAHa_06x36 wrote: post #61
mises wrote: post #4

Earlier quoted context omitted.

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.

The PNaCL and Apple's variants are architecture independent.

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

#88

Post by pjmlp »

Arbalest wrote: post #43
Twirrim wrote: post #35

Earlier quoted context omitted.

It's a really funny monetisation move, releasing everything as open source, putting it all in openjdk (which has been the language reference spec for a while anyway) The only bit being monetised is the Oracle compiled and distributed version of the JVM. If you don't want to pay Oracle, just use OpenJDK, which has all of the same hotspot JIT stuff.

Oracle could have easily done as Google has done with Android, and make sure that the client end wouldn't run without some kind of proprietary extension[a]. They are the world leaders in deploying the Ask toolbar, and with that comes the end users. It is only because we aren't using Java that we don't see this happening. a] Yes you can make android apps run on AOSP, but as many comment with regards to Huawei losing t…

I never had Ask Toolbar on my computer, why would you ask?

1 - I always read what I get proposed to install and disable what I don't care about.

2 - The JDK didn't had such "feature", only the consumer JRE

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

#89

Post by zaarn »

pjmlp wrote: post #86
zaarn wrote: post #65

Earlier quoted context omitted.

Doubtful considering how much work is being done around WASM.

Usually being hyped by people that apparently don't know the history of bytecode formats since the early 60's.

I'm well aware of the history of bytecode formats, Java was pretty successful for a while, even managed to get in the Browser and only failed there due to a lack of a DOM Interaction story and similar integration problems.

There is already plenty of companies that deployed WASM on their stack (like Ebay, they use Wasm for their barcode scanner), it's not going away any time soon.

Post reply on HN