Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code

usenix.org

Post reply on HN
Print view View original

21–30 of 212 posts

Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code

#21

Post by 0815test »

iTokio wrote: post #8

> an offline compiler like Clang can spend considerably more time to generate better code, whereas WebAssembly compilers must be fast enough to run online > [security] checks are necessary for WebAssembly’s safety > current JavaScript implementations reserve a few registers for their own use, which increases register pressure on WebAssembly

Runtime security checks are not necessary for WebAssembly to be safe. You could compile from a memory-safe source language to start with and add support in the WASM format for proof-carrying code. Then all that's needed in the WASM runtime is a static check of the added proof information, which could be very quick. Runtime checks could still be used to run WASM that doesn't carry proofs of safety, keeping the same performance cost.

(Some occasional runtime checks would nonetheless be needed, since safety against e.g. excessive stack use could depend on what the program is doing at runtime; but they would be quite rare and come with very little overhead.)

Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code

#22

Post by gridlockd »

hutzlibu wrote: post #13
Octoth0rpe wrote: post #3

Tl;dr: 2x slower in FF, 2.5x slower in chrome. Depending on the application, that doesn't seem to be a huge tradeoff. Certainly many developers are comfortable writing things in python, which is likely hundreds of times slower than C++ in many problem spaces. TBH though my big hope for web assembly has nothing to do with the web at all, but as a distribution format for drivers that can be installed on any cpu arch/ke…

"Certainly many developers are comfortable writing things in python," But python is a high level script language with gc. WebAssembly is very lowlevel, so the people who could and would write in python will not write in wasm and also not in C. Wasm is still awesome, it is just not, what many hope it will be. And a distribution format for drivers? Well, I am not a low level expert, but that seems very unlikely to work…

The point is that people are clearly willing to leave magnitudes of performance on the table just so that they can use their language of choice.

That's what Webassembly enables today: You can use C/C++, Rust, Go and several others. Of course the ecosystem is not as mature. Languages with a big runtimes aren't good candidates for lean web apps. Performance isn't the dealbreaker though.

Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code

#23

Post by Epskampie »

FpUser wrote: post #16

Ok. At some point in the future the browser/wasm will have won. So instead of Linux/Windows/OSX we will have Firefox/Safari/Chrome/Whatever all with their own implementation gotchas, missing features and performance loss. All for the sake of browser vendors trying to displace the existing native deployment platforms. They sure have nice financial incentive. Why do we - developers fall into this trap? We've been there…

Because this time around we will have instant (no install) apps that are inherently sandboxed? Seems like a pretty big win to me.

Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code

#24

Post by flohofwoe »

FpUser wrote: post #16

Ok. At some point in the future the browser/wasm will have won. So instead of Linux/Windows/OSX we will have Firefox/Safari/Chrome/Whatever all with their own implementation gotchas, missing features and performance loss. All for the sake of browser vendors trying to displace the existing native deployment platforms. They sure have nice financial incentive. Why do we - developers fall into this trap? We've been there…

But it's the other way around. Can you distribute a native application on macOS without Apple's blessing? No, you can't (not when Catalina will be out anyway). And Windows is closing the "gap" really fast too. Try distributing a native installer without the browser or SmartScreen bringing up a scare-dialog-box.

Until OS vendors are willing to provide a safe sandbox to run untrusted code in, and untangled from a non-technical curating mechanism which has all sorts of conflicts-of-interests of what's morally acceptable and what's not, WASM is the next best thing to an open, yet secure, platform.

Desktop Linux aside, the web is currently the only open platform for distributing software outside of the interests of a single "platform owner". Google may close this "loop hole" soon, so I'm not too optimistic for the future, but today, that's what it is.

Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code

#26

Post by gioele »

Epskampie wrote: post #23
FpUser wrote: post #16

Ok. At some point in the future the browser/wasm will have won. So instead of Linux/Windows/OSX we will have Firefox/Safari/Chrome/Whatever all with their own implementation gotchas, missing features and performance loss. All for the sake of browser vendors trying to displace the existing native deployment platforms. They sure have nice financial incentive. Why do we - developers fall into this trap? We've been there…

Because this time around we will have instant (no install) apps that are inherently sandboxed? Seems like a pretty big win to me.

We already had "instant (no install) apps that are inherently sandboxed": Java and its net-top boxes. Why didn't it work?

Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code

#27

Post by megous »

Epskampie wrote: post #23
FpUser wrote: post #16

Ok. At some point in the future the browser/wasm will have won. So instead of Linux/Windows/OSX we will have Firefox/Safari/Chrome/Whatever all with their own implementation gotchas, missing features and performance loss. All for the sake of browser vendors trying to displace the existing native deployment platforms. They sure have nice financial incentive. Why do we - developers fall into this trap? We've been there…

Because this time around we will have instant (no install) apps that are inherently sandboxed? Seems like a pretty big win to me.

Webassembly is not magic. You still have to download and possibly cache code and assests. Call it install or not.

I think win is having free software or at least opensource apps that are trusted by distributors and easy to analyze/modify, and actually own (meaning have on your harddrive and fully control). And we already have that win.

Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code

#28

Post by NoGravitas »

gioele wrote: post #26
Epskampie wrote: post #23

Earlier quoted context omitted.

Because this time around we will have instant (no install) apps that are inherently sandboxed? Seems like a pretty big win to me.

We already had "instant (no install) apps that are inherently sandboxed": Java and its net-top boxes. Why didn't it work?

Timing, probably. Java was too slow in downloading and running on the commodity networks and hardware available at the time. Now that both of those are fast enough, we're seeing another implementation of the same idea.

Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code

#29

Post by jacknews »

jakobegger wrote: post #25

Can someone explain a concrete use case for web assembly? Are there projects out there using web assembly in production? What kind of application needs more performance than Javascript can offer, but doesn't need full native performance?

I think it's more a case of wasm being a more natural target for compilers, meaning you can write or port applications in other languages to the web without the much-worse performance (and size) implications of compiling to interpreted javascript.

Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code

#30

Post by PudgePacket »

iTokio wrote: post #8

> an offline compiler like Clang can spend considerably more time to generate better code, whereas WebAssembly compilers must be fast enough to run online > [security] checks are necessary for WebAssembly’s safety > current JavaScript implementations reserve a few registers for their own use, which increases register pressure on WebAssembly

> > an offline compiler like Clang can spend considerably more time to generate better code, whereas WebAssembly compilers must be fast enough to run online

https://hacks.mozilla.org/2018/01/making-webassembly-even-fa...

> One of these speedups is streaming compilation, where the browser compiles the code while the code is still being downloaded. Up until now, this was just a potential future speedup. But with the release of Firefox 58 next week, it becomes a reality.

> Firefox 58 also includes a new 2-tiered compiler. The new baseline compiler compiles code 10–15 times faster than the optimizing compiler.

Seems to deal with the "whereas WebAssembly compilers must be fast enough to run online"

Post reply on HN