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

Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code

usenix.org

Post reply on HN
Print view View original

161–170 of 212 posts

Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code

#161

Post by hinkley »

AnIdiotOnTheNet wrote: post #131
jayd16 wrote: post #125

Earlier quoted context omitted.

Except you can run wasm on an iPhone. I like Java but it's not like they didn't try Java applets. They really screwed the security model. I guess in that sense what the parent is asking for is actually not nearly as feasible as using the current web security model.

> Except you can run wasm on an iPhone. An arbitrary decision made by the manufacturer. If Apple decided they didn't want to support web assembly tomorrow, do you think that would kill the iPhone or WASM?

An arbitrary decision made by the manufacturer of the phones of customers with the largest discretionary spending budget.

I recall there being an article about how despite the fact that iPhones are 10% of the market, they represented 50% of the profits for application developers.

Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code

#162

Post by hinkley »

flohofwoe wrote: post #46

FWIW: in my 8-bit emulators I'm closer to the 10% performance difference for code compiled in clang with -O3 (the native version uses latest Xcode's clang, the WASM the latest LLVM WASM backend via emscripten): https://floooh.github.io/tiny8bit/cpc-ui.html The time in the top-right is the time spent per frame in the emulator, in the WASM version that's somewhere around 2.5 to 2.8ms on my laptop. The native version is…

But 10% is something I can easily sell to my boss. I only need one or two compensating qualities for that argument to succeed.

If I'm getting work done faster, prioritizing a couple more perf stories is a reasonable tax to pay.

Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code

#163

Post by wiremine »

Paul-ish wrote: post #121
wiremine wrote: post #110

How much of this performance gap is due to the inherent limitations of the WebAssembly technology, and how much is due to it being relatively new? I.e., do we expect to see performance improvements similar to what we've seen in JavaScript over the last two decades? Or are we going to need better hardware to realize better performance?

Section 6.4 tries to answer this question. > It is worth asking if the performance issues identified hereare fundamental. We believe that two of the identified issues are not: that is, they could be ameliorated by improved implementations. WebAssembly implementations today useregister allocators (§6.1.2) and code generators (§6.2.1) thatperform worse than Clang’s counterparts. However, an offlinecompiler like Clang c…

> A redesigned WebAssembly, with richer types for memory and function pointers [23], might be able to perform some of these checks at compile time, but that could complicate the implementation of compilers that produce WebAssembly.

Great info, thanks for sharing! So, to summarize:

Performance will get a bit better for WebAssembly 1.0, but we'll need a WebAssembly 2.0 (for lack of a better term) to realize major performance improvements. And/Or we'll need advancements in JIT technology.

Beyond that, there will always be some limitations because of the Javascript interop requirements.

And, as other threads here have pointed out... maybe who cares? It's still pretty fast!

Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code

#164

Post by cloverich »

AnIdiotOnTheNet wrote: post #149
bastawhiz wrote: post #141

Earlier quoted context omitted.

The difference is that the runtime lives in the browser, based on an open standard. Operating systems come with browsers. The success of WASM is that my mom doesn't need to know how to install Java (and maybe accidentally a Yahoo toolbar) to run an app to look at her DICOM images.

> The difference is that the runtime lives in the browser, based on an open standard. Java is an open standard (I think, I didn't fact check this thuroughly) OpenJDK is the reference implementation of that standard. You can try to claim that in reality Oracle has a lot of control, but I'd come right back and say that Google basically controls the browser. > The success of WASM is that my mom doesn't need to know how…

I appreciate the arguments but they do still rely on _using_ a JVM language _and_ shipping an additional runtime (since browsers are already on all devices in question here). Those are two reasons (in addition to Oracle, which as much hate as Google gets I'd bet people would still take them over Oracle) people are excited about WASM.

Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code

#165

Post by amptorn »

bastawhiz wrote: post #83

So many comments here missing the point. As a developer, I can use wasm to ship a single binary that works on Windows, Mac, Linux, Android, and iOS. I can use the language that I want. I don't need to have Xcode, visual studio, android studio, or any other set of tools: you can reasonably build an app with your text editor and LLVM. And then, you can use my app by typing its address into your address bar. No installa…

What privacy and security attributes does WebAssembly have over a plain old web page?

Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code

#167

Post by Tossrock »

FpUser wrote: post #40
Epskampie wrote: post #23

Earlier quoted context omitted.

Because this time around we will have instant (no install) apps that are inherently sandboxed? Seems like a pretty big win to me.

There is no free lunch in this universe. For big applications like CAD there will be nothing "instant" for in case of deployment as web apps. Downloading native packed archive and running install may actually be faster.

OnShape is pretty darn quick.

Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code

#168

Post by typon »

AnIdiotOnTheNet wrote: post #142
ScottFree wrote: post #137

Earlier quoted context omitted.

The problem lays in the UI. Most of what a modern application does is provide a decent UI to interact with data on a remote server. Swing was a terrible UI library. I never saw a java applet that wasn't ugly and clunky.

And the completely non-native snowflake mobile-first slow-as-hell UIs of today's web are better?

Yes, a million times better.

Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code

#169

Post by EastSmith »

bastawhiz wrote: post #83

So many comments here missing the point. As a developer, I can use wasm to ship a single binary that works on Windows, Mac, Linux, Android, and iOS. I can use the language that I want. I don't need to have Xcode, visual studio, android studio, or any other set of tools: you can reasonably build an app with your text editor and LLVM. And then, you can use my app by typing its address into your address bar. No installa…

Sandboxing is the most underrated browser feature ever. I prefer webapps before any native app just because of the sandboxing. A native app has uncontrolled access to everything on my system (in a usual end user install). Good luck to a browser app that tries to access My Documents or My Pictures.
Post reply on HN