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

111–120 of 179 posts

Re: Analyzing the Performance of WebAssembly vs. Native Code

#111

Post by vanderZwan »

uasm wrote: post #44
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?

> "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?" You're asking for unified, standardized, cross-vendor hardware + instruct…

Theoretically it would let you ditch a lot of outdated instructions for something a lot simpler, enabling smaller, more efficient (power-wise) hardware.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#112

Post by AsyncAwait »

heavenlyblue wrote: post #108
AsyncAwait wrote: post #93

Earlier quoted context omitted.

> Because every single website I visit today on my desktop shows me a popup asking me to enable their desktop notifications. I know what you mean, but that's usually traditional news sites and the like. Having the Spotify web app notify you of the currently playing song or a remainder app reminding you of an appointment is of course a different case, Hence the "web site" vs "web app" distinction I made.

I don’t know: frankly I find them incredibly annoying (that includes Spotify, email and the likes). But besides the point: imo the semantics of these notifications severely differ between applications. Moreover, the usefullness of them heavily depends on the ability for someone to integrate them in the whole ecosystem. Thus notifications from news websites fit right in: they don’t need a snooze button as it in for OS…

But all that is very much true for native app notifications as well. So it may be that you don't like notifications in general, not PWA notifications specifically?

Re: Analyzing the Performance of WebAssembly vs. Native Code

#113

Post by xtian »

NicoJuicy wrote: post #103
crabl wrote: post #17

Apple has shown and continues to show willingness to embrace web technologies once they show clear promise or stability[1]. They might not implement "hemorrhaging edge" technologies immediately, but if the technology supports it, and it contributes positively to the user experience, they will do it. [1]: https://twitter.com/mhartington/status/1089292031548145666

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.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#114

Post by [deleted] »

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…

[deleted]

Re: Analyzing the Performance of WebAssembly vs. Native Code

#115

Post by AnIdiotOnTheNet »

cm2187 wrote: post #77
ghettoimp wrote: post #72

Earlier quoted context omitted.

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 i…

> you are left having to deal with edge cases about platform specific features

Which is always the case. The more you abstract the less you control, the more you need to control the less you can abstract. We've played this game before with Java.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#116

Post by tylerl »

ssebastianj wrote: post #100
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…

There's a joint paper (dated 2017, I think) from engineers from Google, Mozilla, Microsoft, and Apple working on WebAssembly [0] [0] https://blog.acolyer.org/2017/09/18/bringing-the-web-up-to-s... "Bringing the web up to speed with WebAssembly" [PDF]: https://github.com/WebAssembly/spec/raw/master/papers/pldi20...

Apple is willing to "work on" any technology that might affect them, but you can't read a lot into their participation, and it certainly doesn't imply and intent to adopt. Also, Apple is an extremely siloed company in terms of goals, technology, standards, etc. Don't expect the Safari team and the iPhone team to share a common vision.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#117

Post by dmitriid »

expertentipp wrote: post #31
jacobolus wrote: post #16

Earlier quoted context omitted.

Web apps are inherently mediocre on every platform. There’s enough advantage from being accessible via URL, usable on any device, live updating, etc. to compensate that for many uses. But using web apps daily for any serious work is a huge loss in resource use, usability, polish, ... The one that makes me saddest though is that web apps seem to be getting worse over time. For example most of Google’s suite of web app…

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?

Re: Analyzing the Performance of WebAssembly vs. Native Code

#118

Post by writepub »

crabl wrote: post #17

Apple has shown and continues to show willingness to embrace web technologies once they show clear promise or stability[1]. They might not implement "hemorrhaging edge" technologies immediately, but if the technology supports it, and it contributes positively to the user experience, they will do it. [1]: https://twitter.com/mhartington/status/1089292031548145666

The evidence to the contrary is overwhelming. Their W3C compliance is abyamal, and it's certainly NOT because they care for the user.

The way they banned Steam from streaming games, by retroactively changing app-store rules, it appears like the motivation is to increase (app-store) revenues, by crippling the iOS browser.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#119

Post by dmitriid »

onion2k wrote: post #26
fooker wrote: post #21

Earlier quoted context omitted.

The tech is part of the problem. Sure, you can get to the same result eventually. But the tools to do so are better and more intuitive for making Android or iOS apps.

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.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#120

Post by sctb »

crabl wrote: post #17

Apple has shown and continues to show willingness to embrace web technologies once they show clear promise or stability[1]. They might not implement "hemorrhaging edge" technologies immediately, but if the technology supports it, and it contributes positively to the user experience, they will do it. [1]: https://twitter.com/mhartington/status/1089292031548145666

We detached this subthread from https://news.ycombinator.com/item?id=19023701.
Post reply on HN