Seems like the tl;dr is that v8 and spidermonkey need to work on adding more optimization tiers to their wasm piplines
You don't need ‘more’ tiers per se, because WASM can be fully compiled from the outset. Two tiers should be fine.
Analyzing the Performance of WebAssembly vs. Native Code
131–140 of 179 posts
Re: Analyzing the Performance of WebAssembly vs. Native Code
#132Earlier 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?
Java became one of the most heavily used programming languages, so it seems to me like that supports the cross-platform argument.
Re: Analyzing the Performance of WebAssembly vs. Native Code
#133WASM will be the default for any non-trivial web apps in the next few years (assuming the DOM access gets addressed). Why would you ship JavaScript of the internet to then get compiled locally? I know there's arguments for JIT, but I don't think they make sense for JavaScript. Also devs hate JavaScript! Okay, I know we don't all hate it and I know it's popular, but really why does TypeScript exist? It's just a ration…
Does WASM reduce (or at least not-increase) payload size? If not, I'm not sure it's worth it unless the performance improvement is really big.
Re: Analyzing the Performance of WebAssembly vs. Native Code
#134I 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…
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?
Stuff is changing all the time implementation wise, but the architecture of WASM will enable faster-than-JavaScript access to the DOM https://hacks.mozilla.org/2018/04/javascript-to-rust-and-bac...
Also, I think this might be the tipping point where web UI applications begin to be built in WASM-targeting-languages rather than JavaScript
Re: Analyzing the Performance of WebAssembly vs. Native Code
#135Earlier 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?
Java became one of the most heavily used programming languages, so it seems to me like that supports the cross-platform argument.
The topic under discussion is using webasm to write cross-platform user-facing code, and Java never caught on for that purpose.
Re: Analyzing the Performance of WebAssembly vs. Native Code
#136Compilation 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.
The problem is that the compilation budget is much smaller when it impacts the perceived startup time of the application. For a performance critical application it is much easier to throw resources to offline compilation than for online compilation.
Do typical web assembly implementations cache the result of compilation?
Re: Analyzing the Performance of WebAssembly vs. Native Code
#137Earlier quoted context omitted.
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...
All of which is a feature, not a bug: it makes the prompt more expensive to implement and way more intrusive to the user, meaning significantly less likely for drive-by prompter to implement.
Further bonus: no unstable proprietary API to reverse-engineer and implement and it teaches the user that there's nothing specific to it, they can pin any site they commonly use to their home page whether that site provides specific PWA support or not, such that they can perform the action at any point they want.
The browser is simpler, the method is less scammy and the user is empowered.
Re: Analyzing the Performance of WebAssembly vs. Native Code
#138I 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.
If we can get to the point where we're only throwing away 20% performance on web-engine-based programs, I'll be overjoyed.
Re: Analyzing the Performance of WebAssembly vs. Native Code
#139Earlier quoted context omitted.
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.
There's an add to home screen button, but it's buried deep in the share sheet and the average user doesn't know about it. We already have a "X company has an app" banner API on iOS, it seems fitting that webapps have an option to match. And the Safari provided "X company has an app" banner is a lot less annoying than any third party "HEY WHY AREN'T YOU USING OUR APP" banners in that it goes away when you scroll down…
> There's an add to home screen button, but it's buried deep in the share sheet and the average user doesn't know about it.
What? It's a single tap to open the share sheet and the button is in the system row "above the fold" (because there aren't even enough items for anything to even be below the fold). If that's "buried deep" I'd shudder to know what you think of uninstalling an application or adding a keyboard.
Re: Analyzing the Performance of WebAssembly vs. Native Code
#140Earlier quoted context omitted.
Your example, though, directly contradicts the point you're trying to make. Apple does have a native feature for showing when there's a native app available, and -yet- we see those third-party banners. Having the native API to do something doesn't make the third-party crap banners go away.
Yes, not every site wants it to be unobtrusive, they view the nagging as a feature. But for sites that aren't assholes I think they should have a standardized option like the app store's smart banners. I guess the real question is "If we didn't have smart banners, would even more websites use obnoxious full screen popovers and fixed position headers that pop back up every time you visit the page?" I think the answer…
> I think the answer is yes
I think the answer is no: smart banners only increased the pop-over spam, and adding a smart banner is pretty much free, it's a single line to add to a header and is guaranteed to only trigger on the relevant / target population. A hand-rolled version not only is significantly more expensive to implement but it will misfire and lose visitors.