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

111–120 of 212 posts

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

#111

Post by nurettin »

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…

Sure, list clicker apps can ve distributed in such a manner.

On the other hand, I still have no way of distributing my system services easily in a cross-platform way.

Say, I have a service that is triggered when RC45 is jacked in or when a passive scan on a wifi device is completed. I still have to package it for android, ios, osx, linux (rpm, deb, aur) and windows separately.

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

#112

Post by wtetzner »

microtonal wrote: post #54
not_a_cop75 wrote: post #44

Earlier quoted context omitted.

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.

This makes it theoretically possible to run everything via cloud, if you didn't already see that coming. Yes. But my question is why would I want this? I won't own the software anymore. The web has shown over and over again to have far less privacy. The vendor could disappear, change their terms, change their fees any time. As a customer/user you become basically powerless. And for non-cloud applications: what's the…

As I understand it, WASM binaries have a well defined interface and can easily be sandboxed.

Perhaps there would then be a way to just download WASM binaries from the web and run them locally, with your own sandbox restrictions imposed on them.

I think the ability to sandbox these applications (even if they're not delivered over the web) might actually be the more valuable aspect of WASM.

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

#113

Post by runevault »

ScottFree wrote: post #107
em-bee wrote: post #98

Earlier quoted context omitted.

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

Games are also expected to be battery pigs, so doing 60+ FPS GPU rendering instead of however native UIs are rendered helps. Everyone certainly COULD just write their apps as 2d OpenGL but laptop battery life would suffer for it.

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

#114

Post by wtetzner »

microtonal wrote: post #47
0815test wrote: post #38

Earlier quoted context omitted.

> 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?

Who gets to decide which code is trusted?

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

#115

Post by devit »

It looks like there's another issue that is not quite mentioned: the Chrome code generator is using %rbx to point to the start of the WebAssembly memory, which means that the available addressing modes are severely reduced and a register is used up.

It seems like that it could use a %fs or %gs segment override instead (one of which can be programmed arbitrarily at least on Linux), which should be cost-free on all x86-64 processors and would solve the issue.

Once this is changed, the only remaining fundamental unfixable differences would be reduced cache efficiency from the extra bytes for the segment override, and the need to reserve an extra register for the wasm stack pointer.

However, running WebAssembly code in a separate address space would allow to run arbitrary code, although this would have the drawback of higher memory usage and IPC slowdown.

Is there any article discussing the rationale between Firefox and Chrome's current approach and whether they plan to use either segment overrides or process isolation?

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

#116

Post by adwn »

AnIdiotOnTheNet wrote: post #109
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.

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

"Literally everything you said except the part about inflatable tires has been true of wooden wheels for at least 3000 years. Everything old is new again."

Sometimes, reinventing the wheel actually makes sense.

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

#117

Post by bigato »

FpUser wrote: post #94
bigato wrote: post #76

Earlier quoted context omitted.

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

"yes, this is way forward." - I don't think so

Well the alternative is exchanging data, not code. Actually this was the initial idea on the web, hyperlinked data. Look where that brought us. Maybe we could devise a better model with a client (code) that is simple enough and universal enough, and the server providing/receiving only data and not code? That is, instead of me running the publisher's code on my terminal, i run my code on the publisher's data, exchanging data with them. I am not aware of anything to that effect that is universal enough to replace the web. Thus, sandoxing untrusted code as being the way forward.

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

#118

Post by oaiey »

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…

This is to the point. Adding one thing: the availability of a standardized UI stack. WebAssembly vs a docker container is not that different on a server, but the described client is the differentiator to all competitor. The only real contender QT with C++ is quite a tough and insecure (and ugly) package in comparison.

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

#119

Post by titzer »

devit wrote: post #115

It looks like there's another issue that is not quite mentioned: the Chrome code generator is using %rbx to point to the start of the WebAssembly memory, which means that the available addressing modes are severely reduced and a register is used up. It seems like that it could use a %fs or %gs segment override instead (one of which can be programmed arbitrarily at least on Linux), which should be cost-free on all x86…

> the Chrome code generator is using %rbx

The memory base is actually loaded from the instance pointer, and neither of these are pinned to specific registers. They're both allocatable by the register allocator.

> %fs or %gs segment override instead

This is tricky to do for all platforms that V8 supports. I'm not sure it's free; it's still at the very least another prefix.

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

#120

Post by nteon »

snek wrote: post #85
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 mo…

(I'm one of the authors of Not So Fast)

In the paper we build on previous work from our group, Browsix ( https://browsix.org ) to provide a similar level of abstractions to WASI (the syscall layer). We've talked about having Browsix support running programs targeting WASI in the browser.

One of the great things about supporting "Unix" in the browser is that it makes bringing a whole class of already written applications and library into the browser. I'm excited to see what people do with WASI, but its not clear to me what a program designed from the ground up around capabilities would look like!

Post reply on HN