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

71–80 of 179 posts

Re: Analyzing the Performance of WebAssembly vs. Native Code

#71

Post by krapp »

tjpnz wrote: post #53
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…

>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. Still won't be a panacea for the Chromium runtime.

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

Re: Analyzing the Performance of WebAssembly vs. Native Code

#72

Post by ghettoimp »

cm2187 wrote: post #49
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.

It’s not “a bit of convenience” when you are the business owner having to write multiple cheques instead of one, because each platform enforces its own incompatible technologies. Plus there is another big argument. Some app written in wasm is not just compatible with today’s platforms (iOS, Android, MacOS, Windows, etc), but also with tomorrow’s platforms. The lack of apps is probably what killed windows mobile and r…

Hrmn. Isn't this cross-platform argument the same thing we heard for using Java instead of C (write once run anywhere) or, for that matter, using C instead of assembly (portable assembly language)?

Don't get me wrong, this is all to the good. But does WASM have some special way to prevent the various platforms from implementing their own unique, special, and (of course) incompatible APIs?

Re: Analyzing the Performance of WebAssembly vs. Native Code

#73

Post by johneth »

osrec wrote: post #68
davidhyde wrote: post #67

Earlier quoted context omitted.

Case in point. Why do you need web push when you have websockets which safari supports?

So that you can notify users even when they've closed their browser, like you would with a native app.

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

Re: Analyzing the Performance of WebAssembly vs. Native Code

#74

Post by johneth »

Brakenshire wrote: post #60
zapzupnz wrote: post #45

Earlier quoted context omitted.

I'm with you. The potential for websites to add themselves is far too dangerous; the web being open, wild, and dangerous, adding a website to the home screen should only ever be a browser-based task. And no, asking the user for confirmation is never sufficient to stop unsuspecting people from accidentally causing their own compromise. It's a trust thing. Once they trust one dialogue from a legit website, they'll trus…

As far as I’m aware this Add to Home Screen API you’re describing controlled by the website doesn’t exist, adding a PWA is a process controlled by the browser which occurs according to its heuristics, on Chrome it’s something to do with repeated visits to the same site. The only control the website has is a manifest, which sets the icon, loading screen colour, and whether the website can run without browser chrome. E…

I thought you could trigger mobile Safari to hide its chrome when added to the home screen via some meta tag.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#75

Post by fetbaffe »

obl wrote: post #34
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…

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

Re: Analyzing the Performance of WebAssembly vs. Native Code

#76

Post by masklinn »

vardump wrote: post #36
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.

20% performance or, as I like to say, 20% battery life. Anyways, there are good uses for WASM even outside browser. Plugins and when you have multiple architectures you need to deal with. Sandboxing and deterministic memory consumption is a great fit in certain applications. I'd like to use WASM on relatively small embedded devices (even as small as 64 - 256 kB RAM), to provide extendibility, for example.

nebulet is a project to build a µkernel using wasm modules running directly in ring0.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#77

Post by cm2187 »

ghettoimp wrote: post #72
cm2187 wrote: post #49

Earlier quoted context omitted.

It’s not “a bit of convenience” when you are the business owner having to write multiple cheques instead of one, because each platform enforces its own incompatible technologies. Plus there is another big argument. Some app written in wasm is not just compatible with today’s platforms (iOS, Android, MacOS, Windows, etc), but also with tomorrow’s platforms. The lack of apps is probably what killed windows mobile and r…

Hrmn. Isn't this cross-platform argument the same thing we heard for using Java instead of C (write once run anywhere) or, for that matter, using C instead of assembly (portable assembly language)? Don't get me wrong, this is all to the good. But does WASM have some special way to prevent the various platforms from implementing their own unique, special, and (of course) incompatible APIs?

There might be some differences in API. But if your base runtime + UI (html5) + basic apis (http, storage, location, etc) are the same, you are left having to deal with edge cases about platform specific features. That's not really different from the browser compatibility problems web developers consistently run into now.

So from an absolute purist point of view, yes, but practically it will be as cross-platform as it gets.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#78

Post by masklinn »

untog wrote: post #14
forrestthewoods wrote: post #9

Earlier quoted context omitted.

> can't even show a add to home screen native banner. That sounds like a feature.

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 fucking site spamming you to install on your home screen being a stellar experience.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#79

Post by jules »

obl wrote: post #34
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…

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.

The biggest advantage is the same as using Javascript with Electron: being able to use web technologies on the desktop for easy cross-platform GUI applications. WebAssembly addresses two big downsides of that approach: speed, and having to program in Javascript.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#80

Post by AsyncAwait »

johneth wrote: post #73
osrec wrote: post #68

Earlier quoted context omitted.

So that you can notify users even when they've closed their browser, like you would with a native app.

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'd say there's a difference between a 'web site' and a 'web app'. If there's a web app for which you'd allow notifications if it was a native app, why wouldn't you do so for the web app?
Post reply on HN