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

121–130 of 179 posts

Re: Analyzing the Performance of WebAssembly vs. Native Code

#121

Post by philo23 »

NicoJuicy wrote: post #101
philo23 wrote: post #99

Earlier quoted context omitted.

It's been available much longer than 11.3, was this a typo for 1.1.3 when it was actually added?

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 :)

I agree that better/modern PWA support was added only recently, but the actual "Add to Home Screen" option has been around since 1.1.3.

I'll admit it's been little more than a fancy way to add a bookmark to your home screen with the option to hide the browser chrome, but it's been there for a long time.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#122

Post by dmitriid »

markdog12 wrote: post #91
zapzupnz wrote: post #40

Earlier quoted context omitted.

I really get annoyed when I see people talking about the "huge cut of all sales on apps" in isolation, as though hosting high-traffic downloads, handling financial transactions (purchases, in-app purchases, subscriptions, credit card handling, fraud investigation, etc.), and occasional spots of marketing and publicity when an app does particularly well or is featured in the Stories cost nothing. It's not like these t…

> cost nothing Nobody thinks it cost nothing, it's the draconian 30% they object to. Other app stores are offering similar services, with a much lower cut: https://www.unrealengine.com/en-US/blog/announcing-the-epic-... https://blog.discordapp.com/why-not-90-10-3761ebef4eab

They are not nearly anywhere on same scale.

There are ~1400 app releases in App Store per day (all of them need to be reviewed, checked for compatibility etc. etc.).

There are ~2 million apps which have to be hosted, checked, delivered etc.

Then there are push notifications. During WWDC'12 (yes, 7 years ago) Apple was pushing 7 billion notifications daily.

In comparison: Epic store has 4 apps.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#123

Post by untog »

masklinn wrote: post #78
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.

> 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 The banner being a factor… how? iOS has let users add web applications to their home screen for over a decade. > We've all become very used to the App Store but honestly the experience is pretty crappy. As opposed to every fu…

iOS has let users add sites to their home screen, but very very few users know that it's possible, or how to do it.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#124

Post by expertentipp »

dmitriid wrote: post #117
expertentipp wrote: post #31

Earlier quoted context omitted.

On the web the apps are barely usable for the users because the users are acceptable bystanders, not clients. The clients are data hoarders, advertisers, and trackers. In fact a tuned web app focusing on user experience and performance, with the current state of ES, DOM, HTML5, CSS3, and general performance of web browsers would be mindblowing.

> with the current state of ES, DOM, HTML5, CSS3, and general performance of web browsers would be mindblowing. Where can I find this mythical mindblowing app?

Who is asking and how much are they paying?

Re: Analyzing the Performance of WebAssembly vs. Native Code

#125

Post by masklinn »

untog wrote: post #123
masklinn wrote: post #78

Earlier quoted context omitted.

> 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 The banner being a factor… how? iOS has let users add web applications to their home screen for over a decade. > We've all become very used to the App Store but honestly the experience is pretty crappy. As opposed to every fu…

iOS has let users add sites to their home screen, but very very few users know that it's possible, or how to do it.

Not an issue: as the application author, if / when you see that the user seems invested (not at a random point 30 seconds in or some crap like that) you can add callout or button to suggest installing on their device, and provide the relevant steps then.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#126

Post by untog »

masklinn wrote: post #125
untog wrote: post #123

Earlier quoted context omitted.

iOS has let users add sites to their home screen, but very very few users know that it's possible, or how to do it.

Not an issue: as the application author, if / when you see that the user seems invested (not at a random point 30 seconds in or some crap like that) you can add callout or button to suggest installing on their device, and provide the relevant steps then.

So just like an add to homescreen banner, then, except with more steps required by the user, and a requirement by you to customise it for every different UI the user might see it in?

https://developers.google.com/web/fundamentals/app-install-b...

Re: Analyzing the Performance of WebAssembly vs. Native Code

#127

Post by Veedrac »

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 reduced availability of registers, a sub-optimal register allocator, and a failure to effectively exploit a wider range of x86 addressing modes; (2) increased code sizes lead to more instructions being executed and more L1 instruction cache misses; and (3) generated code has more branches due to safety checks for overflow and indirect function calls.

A surprisingly large amount of this boils down to "x86 needs more registers", but there's quite a lot of detail here. It validates my personal experience that Chrome doesn't do a very good job relative to Firefox, for example

> Code generated by Firefox has 1.15× more branch instructions retired and 1.21× more conditional branch instructions retired than native code, while code generated by Chrome has 4.13× branch instructions retired and 5.06× more conditional branch instructions retired.

> Chrome executes 2.9× more instructions and Firefox executes 1.53× more instructions on average than native code.

> On average, Chrome suffers from 3.88× more L1 instruction cache misses than native code, and Firefox suffers from 1.8× more L1 instruction cache misses than native code.

Overall, it was always obvious that Chrome's deficit compared to Firefox was just engineering work, but what is new is figuring out how difficult the native code deficit would be to close. Some aspects are quite straightforward; browsers probably need to develop a more aggressive tier-2 WASM JIT, now that both listed have a tier-1 baseline that is very fast to compile. This should include:

1. a better register allocator,

2. better peephole optimizations,

3. sophisticated loop optimizations.

Unavoidable slowdowns might include:

1. register pressure from reserved registers,

2. stack overflow checks,

3. function table bounds checks.

———

Is this line a typo? I can't make sense of it; I read 1.5 and 1.9 respectively from the table. (There's another mistyped sentence starting ‘Clang,’ but it is not a major issue.)

> On average WebAssembly in Firefox runs at 1.9× over native code and in Chrome runs at 1.75× over native code.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#128

Post by Veedrac »

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.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#129

Post by marcosdumay »

ubercow13 wrote: post #95
krapp wrote: post #71

Earlier quoted context omitted.

>Still won't be a panacea for the Chromium runtime. It will if native WebAssembly applications don't ship in Electron. It's probably inevitable that all WebAssembly applications will ship in Electron until the heat death of the universe, simply due to network effects and inertia, but that doesn't actually have to be the case. It being called "WebAssembly" doesn't mean it has to run in a browser.

Whats the advantage of WA being used for cross platform development if it is not used along with the web stack? It would have a clear advantage if say the main difficulty with writing cross platform native apps was simply writing portable C++, rather than integrating with the various native UI frameworks

Want your web application (server side) to run on both local machine and those crazy "way too many weak cores" ARM servers?

Want your command line application to run on your desktop and phone?

Want to mock that hardware you are creating on your PC, do you can unity test the controller software?

Re: Analyzing the Performance of WebAssembly vs. Native Code

#130

Post by Veedrac »

int_19h wrote: post #39

I wonder if wasm is feasible to target in hardware. I mean, there were hardware Java bytecode implementations, and that's a lot higher level, so it's definitely possible - but is it worthwhile? Are there any idiosyncrasies in wasm that make it slower than x86 or ARM, that could be fixed if the underlying architecture was more accommodating?

WASM is a poor target for hardware, for reasons that don't matter at all to JITs. It has an unbounded stack, its branch instructions use tags rather than relative offsets, its calls use a function table which would be doubly-indirect in hardware, and such.
Post reply on HN