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

101–110 of 212 posts

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

#101

Post by AnIdiotOnTheNet »

kristiandupont wrote: post #96
AnIdiotOnTheNet wrote: post #71

Earlier quoted context omitted.

Yes, declaring the hard parts to be someone else's problem always works out in the end, doesn't it? Hopefully in 20 years, when people are talking about MetaWebAssembly to abstract away the platforms that run on WASM, you'll have a different perspective on what you've said here.

Oh come on. If you are doing any kind of development, you too, are relying on abstractions and someone elses machinery. That doesn't make you lazy or amoral or something.

Yes, but I'm not under the delusion that adding more abstractions will solve the problem. And actually, I really wish there were fewer abstractions because they often just get in the way.

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

#102

Post by inlined »

megous wrote: post #27
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.

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.

[Former developer on the Windows Component and Applications team, renamed Developer Experience team]

There's a big difference between an imperative (e.g. arbitrary code) and declarative installation process. Imperative installation is most common on Windows due to the initial decisions made by the registry designers + the Windows Installer originating from Office and starting with imperative. Declarative installs are common on the Mac where "installation" usually means dragging a binary from the DMG to your Applications folder. OS X then manages OS integrations declared in an app manifiest.

Declarative installations delegate to a system which has a broader view and standard mechanisms to handle state transitions required for installs, upgrades, and uninstalls. Imperative installations frequently leave residue and are hard for even Windows to fix. I spent years of research and have several patents on trying to figure out how to distinguish between "extension points" of the OS and private state to create a sandbox with the necessary pinholes. Even with those tools handy, many software shops see no reason to upgrade because the Windows end user accepts a life of installers.

I see logic in starting from scratch. This time we can create an end user expectation of declarative and (laterally + vertically) sandboxed apps. Hell, that's what we tried to do with Windows 8, but it was unfortunately restricted to the "modern" (aka full screen) apps that never caught on.

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

#103

Post by em-bee »

megous wrote: post #27
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.

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.

but download and run is the point. with webassembly in the browser i don't have to worry that the installation tool will mess up something on my system. if i want to get rid of the application, i only need to clear the cache.

sure, linux is doing that much better, but until we get linux (homebrew for windows?) installers for windows, i'll prefer webassembly, at least for casual use.

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

#104

Post by inlined »

bartq wrote: post #91
PaulHoule wrote: post #34

Earlier quoted context omitted.

Many things. I was involved with Java applets when Java was in beta and one of the most annoying things was that JDK 1.0 did not come with serialization. I would build applets that displayed content generated on the server and serialization-deserialization code could be 2/3 of the program. Most people had a slow net back then, so the download performance was a big deal. JDK 1.1 put serialization in right away, but Ne…

I'd really like to see Flash reborn on WASM. WASM is a standard, so there will be no problems known to software produced and distributed by a private business (Macromedia/Adobe), problems like closed format, resources access control etc.

>I'd really like to see Flash reborn on WASM

Especially since so much of the internet was once on Flash and we're looking at the loss of historical archives.

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

#105

Post by inlined »

BrissyCoder wrote: post #4

It's early days. Calm down. It will speed up.

The reserved registers may always be a problem. It reminds me of the people who complained about massive slowdown in games when Vista released. The games were so optimized to fit in a single page that the few new pieces of state in the window manager caused page thrashing.

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

#106

Post by thanatropism »

AnIdiotOnTheNet wrote: post #101
kristiandupont wrote: post #96

Earlier quoted context omitted.

Oh come on. If you are doing any kind of development, you too, are relying on abstractions and someone elses machinery. That doesn't make you lazy or amoral or something.

Yes, but I'm not under the delusion that adding more abstractions will solve the problem. And actually, I really wish there were fewer abstractions because they often just get in the way.

Adding more abstractions solve existing problems while creating new ones.

But then, this is what humans have been doing since we figured out stone flints.

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

#107

Post by ScottFree »

em-bee wrote: post #98
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…

sure, you can compile an application, but if you want to target everyone, you have to do it on at least 3 architectures (linux, mac, windows) and as a user, i am either lucky if my architecture is supported, or i am scrambling to find an alternative. in my case i actually have all three. so when i see a new application i want to try, i check which one is best supported and then pick that. several apps run only on win…

> sure, you can compile an application, but if you want to target everyone, you have to do it on at least 3 architectures (linux, mac, windows)

Is that really a big deal, though? From what I understand (and I could be wrong, so correct me if I am), most of the headaches involved in multi-platform development is the OS specific UI. Video games, for example, don't find porting to multiple architectures all that challenging because 1) they design for it and 2) they're not expected to adhere to OS UI guidelines.

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

#108

Post by inlined »

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?

Are drivers actually being written in WASM? In Windows, drivers often require kernel-space code, which require a higher level interrupt request level (IRQL). Incorrect dependencies in IRQL are the leading cause of BSOD[0]. If WASM got this right, it would be impressive. It also might mean that compromising the sandbox is Very Dangerous.

[0] IRQL exception was at least the leading cause when I was a Core OS developer for Windows.

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

#109

Post by AnIdiotOnTheNet »

bastawhiz wrote: post #83

So many comments here missing the point. As a developer, I can use wasm to ship a single binary that works on Windows, Mac, Linux, Android, and iOS. I can use the language that I want. I don't need to have Xcode, visual studio, android studio, or any other set of tools: you can reasonably build an app with your text editor and LLVM. And then, you can use my app by typing its address into your address bar. No installa…

Literally everything you said except the part about using the language you want has been true of Java for at least a decade.

Everything old is new again.

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

#110

Post by wiremine »

How much of this performance gap is due to the inherent limitations of the WebAssembly technology, and how much is due to it being relatively new?

I.e., do we expect to see performance improvements similar to what we've seen in JavaScript over the last two decades? Or are we going to need better hardware to realize better performance?

Post reply on HN