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

41–50 of 179 posts

Re: Analyzing the Performance of WebAssembly vs. Native Code

#41

Post by comex »

xiphias2 wrote: post #7

Compilation speed should be part of the benchmarks, as it's critical for WebASM. The best would be to use the Clang optimization setting with the most similar compilation speed to compare runtime speeds. As an example the article mentions suboptimal register allocation, but without compile time comparision there's no way to know if there really is a simple way to improve WebGL implementation.

It's true that Clang can't compete with the JITs in question on speed. Even at the settings with the most comparable quality of generated code, Clang will be much slower, because its internal design is primarily geared towards maximum optimization potential at high optimization levels, with lower optimization levels as more of an afterthought.

But that's beside the point. The paper isn't suggesting switching to Clang or to the algorithms Clang is using. Rather, it's treating Clang's output as an approximation of 'optimal' code generation for the given C code. There are various reasons to compare it to WebAssembly JITs:

- For one, the paper identifies specific reasons the JIT output is slower, which shows potential areas of improvement they could focus on.

- The comparison also provides a sort of upper bound on how much the JITs theoretically could be improved. It's only a weak upper bound; the upper bound of code quality achievable at the required performance levels is lower and would be more relevant, but there's no way to measure that.

- It also indicates the potential of adding a higher tier to the JIT that optimizes very hot code using slower algorithms.

- And finally, most entertainingly, the benchmarks help answer age-old questions like "can WebAssembly replace native code?" :) Or, at least, "for what applications can WebAssembly replace native code and have acceptable performance?"...

Re: Analyzing the Performance of WebAssembly vs. Native Code

#42

Post by esrauch »

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.

The problem is that regular sites that I plan to visit exactly once are just throwing up the banner.

I have seen the add to home screen banner dozens of times and clicked it never. It would quite obviously be better for me if the banner didnt exist.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#43

Post by Jedi72 »

baybal2 wrote: post #37
NicoJuicy wrote: post #32

Earlier quoted context omitted.

They won't add functionality that would compete with the app store. Add to home screen is a good example

I think that "add to home screen" is a stupid browser API, serving no genuine technical necessity. Feature creep of browsers must be forcefully stopped.

What?? This makes no sense.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#44

Post by uasm »

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 + instruction sets.

Why not do this other way around though? "Compile" JS to WASM, then to x86/x64. Finally just execute on the bare metal.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#45

Post by zapzupnz »

baybal2 wrote: post #37
NicoJuicy wrote: post #32

Earlier quoted context omitted.

They won't add functionality that would compete with the app store. Add to home screen is a good example

I think that "add to home screen" is a stupid browser API, serving no genuine technical necessity. Feature creep of browsers must be forcefully stopped.

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 trust it over and over.

Let web sites leave the home screen on my phone the same way web sites have always left my bookmarks/favourites: alone

Re: Analyzing the Performance of WebAssembly vs. Native Code

#46

Post by Vinnl »

endless1234 wrote: post #30
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

Apart from stuff that competes with their app store, like web push, of course

And Service Workers, though admittedly that implementation took long and is apparently still brittle.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#47

Post by moreira »

Jedi72 wrote: post #43
baybal2 wrote: post #37

Earlier quoted context omitted.

I think that "add to home screen" is a stupid browser API, serving no genuine technical necessity. Feature creep of browsers must be forcefully stopped.

What?? This makes no sense.

It's just about showing a banner to add to home screen, and the person is not wrong — there is no technical necessity for it. There is already, and always has been, an "Add to home screen" button in Safari. Since the very start.

Having said that, if PWA support in iOS moves forward I wouldn't be surprised if that API is added to iOS, since then it'd be part of a bigger-picture thing.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#49

Post by cm2187 »

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.

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 resulted in the current duopoly. If all apps become compatible with any platform as long as they implement a standard, then there is a chance for a challenger to break the duopoly.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#50

Post by [deleted] »

NicoJuicy wrote: post #32
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

They won't add functionality that would compete with the app store. Add to home screen is a good example

[deleted]
Post reply on HN