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

71–80 of 212 posts

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

#71

Post by AnIdiotOnTheNet »

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

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.

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

#72

Post by ScottFree »

FpUser wrote: post #49
gridlockd wrote: post #36

Earlier quoted context omitted.

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.

Companies are running webapps on embedded devices now, but I don't buy the ease of hiring excuse. Web devs demand higher salaries than embedded developers and they have more leverage in terms of where they can work (ie: they're flaky as pie crust). Embedded developers are also more likely to pass the hazing ritual known as the programming interview. Where's the upside to hiring web developers in that context?

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

#73

Post by [deleted] »

PaulHoule wrote: post #34
gioele wrote: post #26

Earlier quoted context omitted.

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

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…

[deleted]

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

#74

Post by jackcviers3 »

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

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…

This is it. Let's be honest - the things that make linux difficult are wireless and graphics drivers because the kernel api's keep changing (to prevent vendors from making non-open-source drivers). Why can't we write a unix compatible desktop os whose only difference is running the drivers in userspace?

Something like Redox(1). It's even MIT licensed, so you could include it in a commercial distribution with your own changes if you so chose when you made your gui.

1. https://www.redox-os.org

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

#75

Post by usefulcat »

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…

> Slower at an average of 50% looks acceptable to me for many applications.

Sure, but what about shorter battery life? Granted it would probably not be 50% shorter battery life since there are many other things (screen, disk, networking) that also consumer power, but still..

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

#76

Post by bigato »

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

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…

> So, instead of walled gardens with signed and checked applications (bad). We have to run untrusted and unchecked code

and sandboxed. yes, this is way forward.

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

#77

Post by ScottFree »

AnIdiotOnTheNet wrote: post #66
microtonal wrote: post #42

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

> 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. Won't ever happen for two reasons: 1) The Linux Desktop community would have to admit that there are better ways to do things, and 2) They'd have to agree on what those things are. 20 years of Linux Desktop history show these things to be impossible. Th…

I lack the talent, but I'm definitely interested.

Have you taken a look around Casey Muratori's handmade.network? Or interacted much with the guys who watch Jonathan Blow's livestreams? They make much the same point you do about taking the linux kernel and creating a new userland around it.

Anyone who's interested in working on something like this, email walkinginalinuxuserland@lj3.me. The least we could all do is keep in touch, right?

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

#78

Post by Ididntdothis »

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.

A long time ago they were talking about Java chips. That didn’t materialize and as far as I know there are no chips that run JavaScript natively so I wouldn’t hold my breath for WebAssembly chips.

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

#79

Post by microcolonel »

not_a_cop75 wrote: post #48
cjfd wrote: post #41

Earlier quoted context omitted.

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.

Ultimately the features involved in optimizing WebAssembly are even more variable than they are for Java, so a Jazelle approach is probably even less useful.

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

#80

Post by throwawaywindev »

GeneralMaximus wrote: post #67
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?

Figma ( https://www.figma.com/ ) is a design tool that runs in the browser and makes heavy use of WASM. It's definitely slower than using a native app like Sketch, but not slow enough to be completely impractical. A few design people I work with here in India have switched to Figma from Sketch, and they seem very pleased with the results. I can see WASM becoming useful for enabling apps that do real-time audio/video/…

Everyone likes Figma because of its real time collaboration. The performance is terrible but you put up with it because of the features.
Post reply on HN