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

161–170 of 179 posts

Re: Analyzing the Performance of WebAssembly vs. Native Code

#161

Post by krapp »

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

The advantage is having something more optimal than the web stack for application design, specifically than HTML, CSS and the DOM, which while surprisingly capable given their origins, are still a series kludges and necessary evils.

If we decide that the web stack is what Web Assembly runs in both on and offline, then we're stuck with the limitations of those formats forever, rather then at least trying to come up with something more fitting.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#162

Post by zapzupnz »

johneth wrote: post #74
Brakenshire wrote: post #60

Earlier quoted context omitted.

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.

You can, and that should be sufficient.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#163

Post by int_19h »

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…

Let me rephrase that. Is x86/x64 (or ARM, for that matter) architecture ideal to compile WASM into? Or could a different architecture be designed that would result in better performance?

Re: Analyzing the Performance of WebAssembly vs. Native Code

#164

Post by vanderZwan »

hackcasual wrote: post #147
Veedrac wrote: post #128

Earlier quoted context omitted.

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.

> when you're doing X vs. native is you're implicitly saying "X vs. the best possible situation."

Not really, any sensible benchmark would be "X vs. the most relevant point of comparison".

Re: Analyzing the Performance of WebAssembly vs. Native Code

#165

Post by baroffoos »

greiskul wrote: post #90
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…

You know that in Android, if you as a developer use in app purchases, you have to pay a cut to the play store, right? But the thing is, you can also do payments on your own (although users are much less likely to trust you), in which case there is no cut. This is why I can buy a book in Kindle on my android phone, but no on my dad's ipod. That's what people are asking for. If you want to provide services, sure, charg…

Its the same situation for steam. Steam provides real value for indie devs who can't set up payment systems and download servers but once you get to a large size you are just having all your money sucked out by valve who provide nothing that you couldn't do yourself cheaper.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#166

Post by shrimpx »

andai wrote: post #54
shrimpx wrote: post #27

Earlier quoted context omitted.

Honest question: does webassembly do anything about speeding up the Dom API? For example low-latency text input is non-existent in any browser engine today (short of rendering text using webgl). Does wasm do anything about this?

Are you talking about textarea and input being high latency?

Yeah textarea and also keyboard events. I was wondering because the comment to which I was replying implies that wasm could make the browser the defacto framework for cross platform code. But I don't think this will be the case if the native APIs continue to be low performance.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#167

Post by uasm »

int_19h wrote: post #163
uasm wrote: post #44

Earlier quoted context omitted.

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

Let me rephrase that. Is x86/x64 (or ARM, for that matter) architecture ideal to compile WASM into? Or could a different architecture be designed that would result in better performance?

> "Let me rephrase that. Is x86/x64 (or ARM, for that matter) architecture ideal to compile WASM into? Or could a different architecture be designed that would result in better performance?"

I'm sure you could compile WASM into Japanese or French if you had to. Maybe then, our French-native CPUs would finally be able to process "sudo fais moi un sandwich". My point being, you're asking a very broad, very theoretical question.

Are CPUs these days not performing well enough for most applications? If so, is it necessarily due to the complex instruction sets powering those platforms?

Re: Analyzing the Performance of WebAssembly vs. Native Code

#168

Post by dmitriid »

expertentipp wrote: post #124
dmitriid wrote: post #117

Earlier quoted context omitted.

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

Everyone would pay for a mindblowing performant app. None have appeared.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#169

Post by vanderZwan »

uasm wrote: post #167
int_19h wrote: post #163

Earlier quoted context omitted.

Let me rephrase that. Is x86/x64 (or ARM, for that matter) architecture ideal to compile WASM into? Or could a different architecture be designed that would result in better performance?

> "Let me rephrase that. Is x86/x64 (or ARM, for that matter) architecture ideal to compile WASM into? Or could a different architecture be designed that would result in better performance?" I'm sure you could compile WASM into Japanese or French if you had to. Maybe then, our French-native CPUs would finally be able to process "sudo fais moi un sandwich". My point being, you're asking a very broad, very theoretical…

I'm sure you aren't doing this consciously, but you're answering completely different ones that are easier to dismiss than the original one that more difficult to answer. It comes across as using a straw man.

int_19h is not asking a very broad, theoretical question so much as that it is a difficult question to answer, requiring specific technical know-how about CPUs and compiler design.

Saying that one can compile WASM into Japanese or French is not an answer to "is x86/x64 (or ARM) an ideal target architecture for WASM", so irrelevant.

Whether or not "CPUs these days [are] not performing well enough for most applications" is not relevant for answering GPs question. It's a justification for you not to have to answer his question. But ultimately, whether or not there would be a point to targeting WASM in the hardware is unrelated to whether it is possible, and what the limitations are. Also: did most websites need the performance of V8 when it came out? No, because no website used JavaScript intensely due to its slow performance.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#170

Post by jbergens »

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?

It could get faster and more memory efficient. Here is a nice description of some plans.

https://hacks.mozilla.org/2018/10/webassemblys-post-mvp-futu...

Post reply on HN