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

Analyzing the Performance of WebAssembly vs. Native Code

arxiv.org

Post reply on HN
Print view View original

151–160 of 179 posts

Re: Analyzing the Performance of WebAssembly vs. Native Code

#151

Post by pier25 »

eikenberry wrote: post #148
pier25 wrote: post #3

I never expected WebAssembly to be as fast as native only to be significantly faster than JavaScript. Considering the popularity of Electron, if WebAssembly does get as fast as native or at least 80% there (and that's a really big if) it would easily become the cross platform language for the vast majority of desktop applications. For mobile we will always be dragged down by Apple and its reticence to embrace web tec…

From what I've seen speed isn't usually the issue with Electron based applications (except Atom), the issue is every other performance metric; memory use, disk use, start up time, etc. How will WebAssembly help here? Will it allow Electron to cut its memory use or startup time?

WebAssembly could become the universal crossplatform language and that would open up a lot of possibilities.

From writing a hybrid app and replacing all the native parts with it (so Node in Electron), to even writing everything with WebAssembly and using native GUI.

It is already possible to remove Node and Chrome from a hybrid app by using webviews and Swift in macOS and C# in Windows. We're developing a crossplatform app using that technique and it's awesome. With WebAssembly the native part could be completely crossplatform with comparable performance.

The only project I know that does this is NodeKit but it seems to be a bit abandoned.

https://nodekit.io/

Re: Analyzing the Performance of WebAssembly vs. Native Code

#152

Post by NicoJuicy »

ilikehurdles wrote: post #109
NicoJuicy wrote: post #101

Earlier quoted context omitted.

No, PWA add to homescreen is since 11.3 https://dockyard.com/blog/2017/09/27/encouraging-pwa-install... They do even auto-delete the PWA-apps [Quote] If the user doesn’t use the app for a few weeks, iOS will free up the app’s files. The icon will still be there on the home screen, and when accessed the app will be downloaded again. Not very trustworthy for using a PWA on iOS it seems :)

This applies to all apps, not just PWAs, and can be enabled/disabled. I don’t know what you’re quoting as it doesn’t appear in the link (apologies if it does, perhaps my ctrl+f is malfunctioning), so I don’t know if your source is claiming otherwise.

Is it enabled by default? My source just mentioned auto-removal for PWA, which seems like a weird decision for local databases

Re: Analyzing the Performance of WebAssembly vs. Native Code

#153

Post by pier25 »

Octoth0rpe wrote: post #87
untog wrote: post #14

Earlier quoted context omitted.

Not really. Progressive Web Apps are a much better model for users than the App Store because they get to use the app immediately then decide later whether they want to keep it on their home screen or not. We've all become very used to the App Store but honestly the experience is pretty crappy.

My biggest objection to PWAs is that a significant part of the value of the app store is the constant scanning for various kinds of malware. I'm not sure that there's a way around that, and that makes the various app stores infinitely better in my book. That's all assuming you trust the efficacy of the app store scanners of course, and my trust in google on that is pretty low.

A good solution to that would be if the mobile app stores allowed PWAs. Instead of using Cordova or similar you could just add a URL with the PWA.

Microsoft already does this: https://docs.microsoft.com/en-us/microsoft-edge/progressive-...

Re: Analyzing the Performance of WebAssembly vs. Native Code

#154

Post by onion2k »

dmitriid wrote: post #119
onion2k wrote: post #26

Earlier quoted context omitted.

That depends. I agree that the tooling around hybrid apps is pretty bad (debugging React Native layout issues is painful ), but the tooling around web apps is really good these days, and that carries over to PWAs (and Electron, Ionic, etc) to a large extent. Chrome's perf flame chart is ace, and if you use VS Code you can get decent IDE debugging going. It's fragile and it takes effort to start but it's waaaay better…

By tools people also mean things like: proper layout, access to native APIs, high-performnace animations, and a lot more.

CSS (or Yoga) is proper layout if you know how to use it. Most native APIs are available to JS even on iOS. Most animation is rendered on the GPU in web tech unless you're doing things very wrong. We even have things like Lottie, AirBNB's SVG-based After Effects animation tool.

All this stuff is just done now regardless of what tech you choose. The arguments against web tech are old. The platform has caught up.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#155

Post by emeryberger »

titzer wrote: post #64

Chrome and Firefox performance should be closer, at least in Chrome 72 and 73. I think the comparisons may have been done without trap handler support in Chrome (virtual memory tricks for fast memory bounds checks).

In our experiments with Chrome, we found no difference for SPEC with or without the trap handler.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#156

Post by dmitriid »

onion2k wrote: post #154
dmitriid wrote: post #119

Earlier quoted context omitted.

By tools people also mean things like: proper layout, access to native APIs, high-performnace animations, and a lot more.

CSS (or Yoga) is proper layout if you know how to use it. Most native APIs are available to JS even on iOS. Most animation is rendered on the GPU in web tech unless you're doing things very wrong. We even have things like Lottie, AirBNB's SVG-based After Effects animation tool. All this stuff is just done now regardless of what tech you choose. The arguments against web tech are old. The platform has caught up.

> The platform has caught up.

It has not. There are no tools for the web approaching even a Delphi RAD or a Qt Creator ca 2001.

CSS layouts are a joke, and trying to create anything as complex as a modern app with CSS is a road of blood and tears (go ahead and use CSS to implement something like Sencha. Hell, start with any constrained layout available for most native frameworks and toolsets out of the box).

By "most native APIs" you mean a very small subset deemed more-or-less safe to execute in the browser (you won't ever have full access to, let's say, UIKit, or AVFoundation).

And even if animation is rendered on GPU, 1) if you have a lot of them, the browser will struggle, and 2) web animations are extremely limited, primitive, and extremely constrained by layout. Good luck not running into reflow issues for animations which are a breeze on the native platforms. And good luck working around these issues using only animations which won't trigger them.

> All this stuff is just done now regardless of what tech you choose.

There are people who build OSes using only assembly. It doesn't mean that tools or capabilities of assembly are anywhere near available for other tech.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#157

Post by unnouinceput »

Veedrac wrote: post #127

Summary: > Root Cause Analysis and Advice for Implementers: > We conduct a forensic analysis with the aid of performance counter results to identify the root causes of this performance gap. We find the following results: (1) code compiled to WebAssembly yields more loads and stores than native code (2.1× more loads and 2× more stores in Chrome; 1.6× more loads and 1.7× more stores in Firefox). We attribute this to re…

Yes, a mistake on their part. They changed now to properly show that WASM is slower (not faster) then native code. Now it reads: "applications compiled to WebAssembly run slower by an average of 50% (Firefox) to 89% (Chrome)"

Re: Analyzing the Performance of WebAssembly vs. Native Code

#158

Post by markdog12 »

nerdponx wrote: post #133
mgamache wrote: post #84

WASM will be the default for any non-trivial web apps in the next few years (assuming the DOM access gets addressed). Why would you ship JavaScript of the internet to then get compiled locally? I know there's arguments for JIT, but I don't think they make sense for JavaScript. Also devs hate JavaScript! Okay, I know we don't all hate it and I know it's popular, but really why does TypeScript exist? It's just a ration…

Does WASM reduce (or at least not-increase) payload size? If not, I'm not sure it's worth it unless the performance improvement is really big.

It reduces size, but perhaps more importantly, reduces parsing time, which is crucial, particularly for slow mobile devices.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#159

Post by osrec »

johneth wrote: post #145
osrec wrote: post #85

Earlier quoted context omitted.

I think it's laughable that you differentiate between the notifications of an app vs the notifications from a web app. Both are opt-in, with web apps being even more explicit about the opt-in process, in my opinion. Also, once you disallow notifications, the web app will not be able to request permissions again. Why do you feel this is problematic?

It's easy to disable notifications for native apps (on iOS at least) - just don't grant the permission in the first place. The reason I feel web notifications are more problematic is the nagging aspect that I think would happen (like, for example, the 'install our app' interstitials and prompts). That's annoying enough without adding notifications to the mix.

I sort of agree with you. The web is the wild west, reckless and unrestricted. The app stores are considerably more tame, yet intrinsically restrictive in many ways. Eventually we will tame the web app/PWA ecosystem, while keeping things much more flexible than the app stores. I agree some aspects of PWAs are a little rough round the edges (as you described), but there is plenty of polishing ongoing, and I bet PWAs will eventually emerge shinier than their native counterparts.
Post reply on HN