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

171–179 of 179 posts

Re: Analyzing the Performance of WebAssembly vs. Native Code

#171

Post by tjpnz »

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 main difficulty with cross platform native apps is that nobody's willing to pay for C++ devs with UX experience anymore. Electron makes such things possible even at the expense of code quality and performance - but by that point you simply won't care.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#172

Post by yellowapple »

hollerith wrote: post #135
TheCoelacanth wrote: post #132

Earlier quoted context omitted.

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.

It caught on plenty for that purpose. See also: Minecraft and Android.

It probably would've caught on more/sooner on the desktop if it had adopted a native-look-and-feel GUI toolkit earlier rather than later. Hopefully a WASM reincarnation of Java's cross-platform goals will prioritize that sort of look-and-feel integration.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#174

Post by hollerith »

yellowapple wrote: post #172
hollerith wrote: post #135

Earlier quoted context omitted.

The topic under discussion is using webasm to write cross-platform user-facing code, and Java never caught on for that purpose.

It caught on plenty for that purpose. See also: Minecraft and Android. It probably would've caught on more/sooner on the desktop if it had adopted a native-look-and-feel GUI toolkit earlier rather than later. Hopefully a WASM reincarnation of Java's cross-platform goals will prioritize that sort of look-and-feel integration.

Android certainly satisfies the user-facing requirement, but not the cross-platform.

Specifically, if all we knew about user-facing Java was that most Android app are written in Java (or something that differs from Java only enough to try to avoid infringing the intellectual property rights of Java's owner) then we would expect many cross-platform user-facing apps to be written in Java.

But we have no need for such indirect evidence because we can directly count the cross-platform user-facing apps that are written in Java. You mentioned one, Minecraft, and I will add Eclipse, IntelliJ and its derivatives and Jin (a "client" used to connect to the Free Internet Chess Server and Internet Chess Club). Since I know how hundreds of user-facing cross-platform apps are implemented, and since four out of hundreds is not much, I stick to my claim that Java never caught on for writing cross-platform user-facing code.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#175

Post by yellowapple »

hollerith wrote: post #174
yellowapple wrote: post #172

Earlier quoted context omitted.

It caught on plenty for that purpose. See also: Minecraft and Android. It probably would've caught on more/sooner on the desktop if it had adopted a native-look-and-feel GUI toolkit earlier rather than later. Hopefully a WASM reincarnation of Java's cross-platform goals will prioritize that sort of look-and-feel integration.

Android certainly satisfies the user-facing requirement, but not the cross-platform . Specifically, if all we knew about user-facing Java was that most Android app are written in Java (or something that differs from Java only enough to try to avoid infringing the intellectual property rights of Java's owner) then we would expect many cross-platform user-facing apps to be written in Java. But we have no need for such…

"Android certainly satisfies the user-facing requirement, but not the cross-platform."

Depends on how you define "platform". Android apps certainly run on multiple architectures (mostly ARM, but also x86 and MIPS). They also run on non-Android operating systems (namely: ChromeOS; theoretically-speaking, other operating systems could run Android apps, too, so long as Dalvik runs on those operating systems, though unfortunately this is not the case for most operating systems).

And sure, we can provably claim that Java didn't "catch on" compared to the sheer volume of user-facing programs written in C or C++, but by that logic macOS didn't "catch on" compared to the sheer volume of user-facing computers running Windows (which might indeed be true depending on how you define "catch on").

Re: Analyzing the Performance of WebAssembly vs. Native Code

#176

Post by hajile »

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…

Every other popular scripting language is much slower in comparison across almost every benchmark, yet you don't hear complaints about writing an application with some other scripting language (eg, python).

The problem isn't JS performance -- scripting performance crown was won over a decade ago. The issue is DOM being slow. If you write bindings to a native GUI framework and write your app in JS, performance is going to be extremely acceptable. The biggest issue is that most JS devs aren't comfortable in that universe.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#177

Post by austincheney »

hajile wrote: post #176
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…

Every other popular scripting language is much slower in comparison across almost every benchmark, yet you don't hear complaints about writing an application with some other scripting language (eg, python). The problem isn't JS performance -- scripting performance crown was won over a decade ago. The issue is DOM being slow. If you write bindings to a native GUI framework and write your app in JS, performance is goin…

It isn’t even DOM performance. DOM performance has been fast for about 9 years. The problem is not the DOM but rather all the slow abstractions, including query strings, insecure developers cannot live without.

If you are comfortable with the standard DOM methods your UI performance should generally be about 25% of JavaScript execution speed with exception to the visual render of large DOM node injection. It’s typically fast enough that you wouldn’t be able to tell the difference in performance compared to a GUI written in efficient native code.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#178

Post by inDigiNeous »

jacobolus wrote: post #15
quangio wrote: post #12

The benchmark seems to use only browsers' built in VMs to run WebAssembly (more like the the efficiency of different VM JIT compilers compared to native). How about running them in standalone webassembly VM like WAVM (it does more aggressive optimization, use LLVM for JIT), Asmble (running in JVM), or Wasmer (use Cranelift like Firefox does, maybe a little bit faster than Firefox) (I just skimmed the paper, sorry if…

Speed when running in the browser is probably the main practical concern for most folks using wasm....

That and distribution of applications without having to provide the source, although currently you can of course minimize and compile the source, but still it's much more readable than an actual assembly -output.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#179

Post by hajile »

austincheney wrote: post #177
hajile wrote: post #176

Earlier quoted context omitted.

Every other popular scripting language is much slower in comparison across almost every benchmark, yet you don't hear complaints about writing an application with some other scripting language (eg, python). The problem isn't JS performance -- scripting performance crown was won over a decade ago. The issue is DOM being slow. If you write bindings to a native GUI framework and write your app in JS, performance is goin…

It isn’t even DOM performance. DOM performance has been fast for about 9 years. The problem is not the DOM but rather all the slow abstractions, including query strings, insecure developers cannot live without. If you are comfortable with the standard DOM methods your UI performance should generally be about 25% of JavaScript execution speed with exception to the visual render of large DOM node injection. It’s typica…

DOM has always been incredibly slow. Quantum showed that CSS layout has been incredibly slow. Servo showed that HTML layout is incredibly slow. In addition, the DOM is extremely memory intensive no matter what you use.

A great example is VS Code switching from HTML to Canvas for Terminal. Performance increased by several times. React Native is another example. It performs much better than a Webview even though it still uses JS. Gnome and GJS perform better than any electron app out there while using way less memory.

I assume that when you say query string, you are talking about document.querySelector() rather than the actual query string in the URL. Modern apps using something like React almost never use those. Even with a lot of care, those apps will still be slower than apps written with native GUI frameworks.

Post reply on HN