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

141–150 of 179 posts

Re: Analyzing the Performance of WebAssembly vs. Native Code

#141

Post by xenonite »

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…

According to the paper, "the mean slowdown of WebAssembly vs. native across SPEC benchmarks is 1.43× for Firefox".

Calculating 1/1.43 = 70%, which is close to 80% already today.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#142

Post by hinkley »

fetbaffe wrote: post #75
obl wrote: post #34

Earlier quoted context omitted.

What's the point of using this for native applications ? I mean yeah, it might be a little easier to distribute but it's kind of absurd to agree to throw away 20% performance for a bit of convenience and then sched tears on how the latest intel chips only delivered 5% improvement over the previous ones.

In my opinion it is not the performance of JavaScript or WebAssembly that is the real problem, it has not been for the past few years, it is the performance of the entire web stack (e.g. electron) that is the problem. Combining all of the technologies in the web stack has performance hit far higher than 20%.

One of things I find myself having to teach people over and over again about performance:

It's like personal finance. At the end of the day you are not going to 'balance the checkbook' by identifying the 2 places where you are misbehaving the worst. You have to get every aspect of your spending below a % of your overall budget or you will always be in debt. Starting with the big things can be very motivational but it's not a strategy that works (or rather, it works by accident).

The relevant part for this discussion is that if you fix the slowest thing, (interpreting code) then the effects of all of the other sources of slowness are magnified. Everything else gets 'slower' by comparison (if you fix the thing that takes 50% of the time, then all of the things that used to take single digit percentages jump to double digits). You'll eventually get near your goal that way but the entire process is a game of whack-a-mole, and nobody will ever support you going back for the last 2% in some section of the code, leading to death by a thousand cuts (and honestly, I've watched a lot of people interpret performance reports and most of us can't even spot problems that small.)

Re: Analyzing the Performance of WebAssembly vs. Native Code

#143

Post by tachyonbeam »

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…

This isn't very surprising. C compilers have developed all kinds of low level optimizations over decades, trying to extract the last bits of performance they could. In contrast, JIT compilers for JS focused on recovering missing type information through type inference and other low-hanging fruits.

It's also the case that there's a lot more pressure on JS JITs to produce code fast, and so running multiple passes of low level optimizations was not desirable in a web context. This is somewhat bad news for WASM: better low level optimizations could mean longer compilation times. However, AFAIK, Chrome has been working on caching compiled code, so you may only have to compile WASM when it changes (or when you reinstall/update your browser).

Re: Analyzing the Performance of WebAssembly vs. Native Code

#144

Post by mgamache »

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.

AFAIK it does reduce the overall size for equivalent code.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#145

Post by johneth »

osrec wrote: post #85
johneth wrote: post #73

Earlier quoted context omitted.

The last thing I want is for websites to send me notifications (or rather, endlessly nag me to enable notifications, as I'd never grant permission).

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.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#146

Post by freeopinion »

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.

Yes. WASM reduces the payload size.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#147

Post by hackcasual »

Veedrac wrote: post #128
hackcasual wrote: post #11

They disable vectorization on native, so hard to call this a true apples-to-apples comparison

It makes sense since WASM's SIMD isn't ready yet, and a paper saying “WASM is slower because SIMD isn't ready yet” would be rather uninformative to browser vendors.

I think the problem when you're doing X vs. native is you're implicitly saying "X vs. the best possible situation." I think it's fine to compare it against vector-less operations, but they should also benchmark against more vanilla native compiler settings.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#148

Post by eikenberry »

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?

Re: Analyzing the Performance of WebAssembly vs. Native Code

#149

Post by wlesieutre »

masklinn wrote: post #139
wlesieutre wrote: post #88

Earlier quoted context omitted.

There's an add to home screen button, but it's buried deep in the share sheet and the average user doesn't know about it. We already have a "X company has an app" banner API on iOS, it seems fitting that webapps have an option to match. And the Safari provided "X company has an app" banner is a lot less annoying than any third party "HEY WHY AREN'T YOU USING OUR APP" banners in that it goes away when you scroll down…

> There's an add to home screen button, but it's buried deep in the share sheet and the average user doesn't know about it. What? It's a single tap to open the share sheet and the button is in the system row "above the fold" (because there aren't even enough items for anything to even be below the fold). If that's "buried deep" I'd shudder to know what you think of uninstalling an application or adding a keyboard.

Ah, maybe my share actions are in a nonstandard order, I have to scroll way to the right to find that one.

And in answer to your last point, I'm not optimistic about the average user's ability to add a keyboard either.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#150

Post by NicoJuicy »

xtian wrote: post #113
NicoJuicy wrote: post #103

Earlier quoted context omitted.

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 So much for PWA's on iOS... Apple's willingness to embrace web technologies is a joke.

I don’t see your point. This happens with native apps as well.

Source? Can't find it
Post reply on HN