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

41–50 of 212 posts

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

#41

Post by cjfd »

microtonal wrote: post #32

Slower at an average of 50% looks acceptable to me for many applications. However, for me personally I wonder: what's the point? I would go from Linux -> glibc -> native application to Linux -> glibc -> Web Browser -> WebAssembly application. Yet another layer of abstraction. Sure, WebAssembly can be run directly on any platform. But precompiling an application is not a problem (my Linux distribution provides binary…

People might start baking chips that can natively run web assembly at some point. If that happens we have found a very expensive path from running native binaries to running native binaries for the purpose of making this independent of the platform.

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

#42

Post by microtonal »

flohofwoe wrote: post #24
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-t…

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).

Yes you can:

https://forums.macrumors.com/threads/unsigned-apps-catalyst-...

WASM is the next best thing to an open, yet secure, platform.

So, instead of walled gardens with signed and checked applications (bad). We have to run untrusted and unchecked code of vendors who run code to track your movements around the web and in their applications? (Even worse)

Desktop Linux aside

Maybe we should make Linux an acceptable platform for more people rather than optimizing for proprietary web applications that you don't even own a copy of anymore.

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

#43

Post by Octoth0rpe »

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

You don't mind drivers being half as performant as they were before, with the only benefit being they're easier to distribute? Why? How is that beneficial to anyone except the person packaging the driver?

> You don't mind drivers being half as performant as they were before, with the only benefit being they're easier to distribute?

A different way of phrasing this would be "would you prefer a driver that uses 2% of your cpu vs no driver at all? Note that if the hypothetical non-existent driver was written in c, it would only take 1% of your cpu"

> Why?

Because the alternative for many alternative OSes is no driver at all.

> How is that beneficial to anyone except the person packaging the driver?

Because if it's more convenient for the packager, then there's a better chance that they'll package a driver that way, which means I'm more likely to actually get the driver in the first place.

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

#44

Post by not_a_cop75 »

microtonal wrote: post #32

Slower at an average of 50% looks acceptable to me for many applications. However, for me personally I wonder: what's the point? I would go from Linux -> glibc -> native application to Linux -> glibc -> Web Browser -> WebAssembly application. Yet another layer of abstraction. Sure, WebAssembly can be run directly on any platform. But precompiling an application is not a problem (my Linux distribution provides binary…

The point is obviously that web apps can be directly competitive with binaries, sans the same level of security, given they operate a lite version of the application. This makes it theoretically possible to run everything via cloud, if you didn't already see that coming.

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

#45

Post by FpUser »

kowdermeister wrote: post #20
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…

> Why do we - developers fall into this trap? Regardless of is this a trap or not, it's obvious to me that developers want simplicity and consistency. WA provides both so don't wonder why it's taking off. > So instead of Linux/Windows/OSX we will have Firefox/Safari/Chrome/Whatever all with their own implementation gotchas I let the compilers worry about this :)

Yeah, right. Compilers do not deal with the difference in presence / absence and different implementations of various features on different platforms, be it native OS or Browser OS.

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

#46

Post by flohofwoe »

FWIW: in my 8-bit emulators I'm closer to the 10% performance difference for code compiled in clang with -O3 (the native version uses latest Xcode's clang, the WASM the latest LLVM WASM backend via emscripten):

https://floooh.github.io/tiny8bit/cpc-ui.html

The time in the top-right is the time spent per frame in the emulator, in the WASM version that's somewhere around 2.5 to 2.8ms on my laptop.

The native version is somewhere between 2.0 and 2.2ms.

From my experiments, it's quite easy to accidentally hit a "slow path" on the WASM side, for instance registers are spilling earlier (AFAIK because WASM has one or two registers set aside). Things are getting better though. About a year ago, the same emulator code seemed to have triggered some specific slow-path and the WASM version was nearly 4x slower.

Of course it's always possible to put more time into optimizing the native version of a piece of code when targeting a specific compiler version, compiler-specific intrinsics and a specific CPU model. This is where WASM will always lag behind, with a portable ISA you'll always hit a wall where further optimization simply isn't possible.

So from my experience: somewhere between 10% slower and 3x slower is all within the "expected" range, the more important part is that performance is predictable for a given piece of code compiled with a given compiler version (e.g. you won't have the GC come in and do its thing for a few hundred milliseconds). And at least the emscripten team is very responsive and interested in such pathological cases.

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

#47

Post by microtonal »

0815test wrote: post #38
flohofwoe wrote: post #24

Earlier quoted context omitted.

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

> Until OS vendors are willing to provide a safe sandbox to run untrusted code in Thing is, "safe" OS-sandboxes are not safe; "local" privilege escalation vulnerabilities are still pervasive. Until OS's are safe enough that I can run `sudo -u nobody untrusted_binary` and not even think about the possibility of it taking over my system, something like the WASM sandbox (perhaps extended with WASI and other optional mec…

The the browser sandbox is just another sandbox, as we have seen with targeted attacks on Firefox two weeks back.

Why is everybody so insistent on running untrusted code?

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

#48

Post by not_a_cop75 »

cjfd wrote: post #41
microtonal wrote: post #32

Slower at an average of 50% looks acceptable to me for many applications. However, for me personally I wonder: what's the point? I would go from Linux -> glibc -> native application to Linux -> glibc -> Web Browser -> WebAssembly application. Yet another layer of abstraction. Sure, WebAssembly can be run directly on any platform. But precompiling an application is not a problem (my Linux distribution provides binary…

People might start baking chips that can natively run web assembly at some point. If that happens we have found a very expensive path from running native binaries to running native binaries for the purpose of making this independent of the platform.

Lol. Well, I mean nothing is outside of the realm of possibility, but remember those native Java chips! Some thought those were going to be a big win. And then you had companies like Transmeta trying to do the exact opposite - interpretively optimize all the things....or something like that.

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

#49

Post by FpUser »

gridlockd wrote: post #36
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…

I don't see it this way at all. Browser vendors have been very reluctant to accept that they're now supposed to provide a real application development platform. It's businesses that demand web applications, because native deployment (in-house or for customers) is a tougher sell. A lot of it has to do with the bad security model of desktop operating systems combined with the overhead of administration. Last but not le…

"...Last but not least, web developers are the biggest pool to hire from..." For boiler plate business web apps sure. And while those are probably being prevalent the world does not stop there.

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

#50

Post by nerdponx »

flohofwoe wrote: post #24
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-t…

I recently switched to desktop GNU/Linux full time outside of work, and I have to say it's really damn good now.

Mind you, I'm using a Lenovo laptop, so it's among the best supported hardware you can buy for the purpose. But the fact that there aren't more boutique computer makers selling GNU/Linux systems installed by default is an interesting statement on the industry.

I'm sure ultimately it comes down to the availability of software like Microsoft Word, but ironically having so much stuff move to the cloud is a boon in this case. With so many web-based apps available, nontechnical people can switch from Windows to a well-configured GNU/Linux system and not notice much of a difference.

With that problem out of the way, a hypothetical hardware vendor can focus on building sane defaults, a good user experience, and good documentation (good for users, not developers). Then if and when it works out and marketshare ends up in double digits, more non-web software will start to become available anyway, and/or a lot more corporate money could start flowing into established projects like LibreOffice.

Obviously the Chromebook was a thing, and you can buy System76 machines today, but the former was too extreme and the latter is probably too expensive for grandma just checking her email.

I assume the reason it doesn't exist it is because the logistics and economics of the hardware don't work out. But I wonder if it will become feasible some time in the near future.

Post reply on HN