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

81–90 of 212 posts

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

#81

Post by idle_zealot »

bitwize wrote: post #61
microtonal wrote: post #47

Earlier quoted context omitted.

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?

Because the Web won't work without running untrusted code.

The Web of hyperlinked documents would still work. But webapps would not be able to run arbitrary code the moment they were navigated to. Perhaps there should be a clear user-visible distinction between an HTML document with some styling and a full-blown application (that happens to use DOM for layout).

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

#82

Post by AnIdiotOnTheNet »

ScottFree wrote: post #77
AnIdiotOnTheNet wrote: post #66

Earlier quoted context omitted.

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

Yes, I've hung out on Johns and Casey's streams. I don't bother much with handmade.network because very little there interests me. Essence is kinda neat, but it is a long way from practicality and I'm not sure how much my ideals and Nakst's align.

I also think a forum or IRC channel would be more appropriate, but email is a start and I appreciate you taking the initiative.

See also Probono's Hello[0], but I'm not sure he hasn't decided that Haiku already fits for him.

[0] https://github.com/probonopd/hello

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

#83

Post by bastawhiz »

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 installation needed. No polluting your home directory. No registry entries. It's sandboxed, you're never giving the app permissions that you don't intend. A service worker can be used to make the app available offline. My dear grandmother could use this without confusion. My dad can use these apps and feel confident he's not not infesting himself with malware or bundled software.

The complaints about "the web doesn't feel native!" and "it's less secure!" and "it's just as easy to ship a native app [for my platform of choice]!" are tired arguments. We've finally got a simple way to distribute apps fully cross platform in a way that CAN respect privacy and guarantees a reasonable level of security. And, it's pretty darn fast.

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

#84

Post by Sean1708 »

jtbayly wrote: post #5
mikece wrote: post #2

So... don't completely discard native desktop apps just yet? That said, I suspect we'll soon see something akin to Eelctron for WebAssembly: a toolkit for making UIs that acts as a permissions context/bridge to making calls into the host operating system's API. Or maybe WebAssembly won't be the revolutionary tidal wave of change that many of its proponents hope it will be?

Won’t that be a security nightmare?

Surely it wouldn't be any more of a security than a native app, since this hypothetical Electrasm would itself be a native app?

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

#85

Post by snek »

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…

The thing I'm most excited about right now is WASI. It provides abstractions for system calls like fs, sockets, graphics, etc. But the best part is that the entire API is being designed with security and capabilities in mind. WASM binaries have to explicitly declare resources they want access to, or risk not being allowed to access them. (The application could also choose to further prompt the user, but i think in most cases they will just be denied). Once resources are acquired, we use unforgable handles to refer to them. It is a super cool and declarative way to make sure people know exactly what a wasm bin will try to access before it's even run.

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

#86

Post by [deleted] »

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…

[deleted]

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

#87

Post by RubenSandwich »

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.

I don't know you are being downvoted. There are already instructions in ARM chips to help with JS floating-point conversion [1]. Yes, while the "Java chips" never got into the mass market[2], JS and it's ecosystem is eatting the world in a way Java never did and the trajectory is only increaing.

P.S. I know WASM isn't JS, but I'd still consider it in the JS ecosystem.

[1]: https://stackoverflow.com/questions/50966676/why-do-arm-chip...

[2]: I did hear about some "Java Chips" for garbage collection back in the day.

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

#88

Post by smallWheel »

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.

The web assembly application could also be compiled to a native binary, right? (something like an AOT compiled electron app)

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

#89

Post by eitland »

jacknews wrote: post #18

I would say even 50% slow down is a fair trade-off for very many applications, for the benefit or running almost anywhere, without installation etc. That was java's claim (but not the reality), what's the slowdown there?

In a lot of cases Java is faster than what average developers would write in C.

That is except startup time.

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

#90

Post by azakai »

PudgePacket wrote: post #30
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 re…

Streaming and tiering do help, and I believe all browsers do that. Still, the article's point is valid that offline compilers can spend more time compiling, because even if you have a faster tier before you, running a slower compiler eats up battery and increases the time before the code runs at full speed.
Post reply on HN